Method, device and equipment for private key component holding certification in collaborative signature

Abstract

The invention relates to the technical field of security protocols, and particularly provides a method, device and equipment for private key component holding certification in collaborative signatures, the method is applied to a first terminal in a collaborative signature system, and the collaborative signature system further comprises 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 comprises the steps that data to be verified are determined based on key parameters, and the key parameters comprise a first private key component, a public key corresponding to a private key and a random number; the to-be-verified data comprises first data and second data; and sending to-be-verified data to a second terminal, so that the second terminal determines whether the second private key component is matched with the first private key component based on the to-be-verified data. Some embodiments of the application can determine the security of private key component storage, and improve the security of collaborative signature or decryption.

Description

Technical Field

[0001] This application relates to the technical field of security protocols. Specifically, it relates to a method, apparatus, and device for proving the possession of private key components in collaborative signature. Background Art

[0002] With the development of cloud computing, big data, and Internet of Things technologies, collaborative signature plays an increasingly important role in ensuring data security and promoting multi-party collaboration. With the rapid development of current mobile Internet technologies, generating user keys and running cryptographic algorithms in mobile terminal APPs has gradually become a mainstream application requirement. In existing collaborative encryption schemes, user private keys are usually divided into two private key components and stored in different terminals. When performing signature or decryption operations, terminal interaction is required to jointly generate a signature value or decrypt ciphertext. In the process of collaborative decryption, when any collaborating party executes the collaborative decryption process, it needs to use its own private key component to perform relevant operations; these operations may be exploited by malicious attackers to deceive the collaborating party into performing decryption actions on specific ciphertexts, thus easily causing unauthorized use of private keys or leakage of security-sensitive parameters.

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

[0004] Some embodiments of this application aim to provide a method, apparatus, and device for proving the possession of private key components in collaborative signature. Through the technical solutions of the embodiments of this application, the security of the storage of private key components can be determined, enabling the establishment of a trust relationship among collaborating parties in the collaborative signature system and ensuring the security of collaborative signature or decryption.

[0005] In a first aspect, some embodiments of this application provide a method for proving the possession of private key components in collaborative signature. This method is applied to a first terminal in a collaborative signature system, and the collaborative signature system further 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 method includes: determining data to be verified based on key parameters, where 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; 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.

[0006] Some embodiments of the present application send the data to be verified obtained by the first terminal calculating the key parameters to the second terminal, so that the second terminal can confirm whether the private key components stored in the two terminals match based on the data to be verified; in this way, it can be confirmed whether the private key components stored between the two terminals are safe and effective, and it can resist malicious attackers from impersonating any terminal to initiate a collaborative process to another terminal, further improving the security of the collaborative signature system. At the same time, before performing collaborative signature or decryption, checking and confirming that the private keys held by both parties participating in the collaborative signature match can effectively avoid the terminal from executing the cryptographic protocol with malicious participants, 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] The types of the first terminal and the second terminal in some embodiments of the present application can be flexibly set, and the practicability is relatively wide.

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

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

[0011] In a second aspect, some embodiments of the present application provide a method for proving the possession of a private key component in collaborative signature. The method is applied to the second terminal in a collaborative signature system, and the collaborative signature system further 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 the data to be verified sent by the first terminal, where the data to be verified is obtained by any method embodiment in the first aspect; the data to be verified includes: the first data and the second data; determining a verification parameter based on the second private key component and the data to be verified; and confirming whether the second private key component matches the first private key component according to the verification parameter and the data to be verified.

[0012] In some embodiments of the present application, the second terminal determines whether the private key components at both ends match based on the received data to be verified and the second private key component, thereby achieving accurate verification of whether the private key components match, effectively resisting malicious attackers from impersonating any terminal to initiate a collaboration 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 verification parameter from the second private key component and the first data; and confirming whether the second private key component matches the first private key component according to the verification parameter and the data to be verified includes: if it is confirmed that the verification parameter is the same as the second data, then the second private key component matches the first private key component; if the verification parameter is different from the second data, 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 verification parameter from the second private key component and the second data; and confirming whether the second private key component matches the first private key component according to the verification parameter and the data to be verified includes: if it is confirmed that the verification parameter is the same as the first data, then the second private key component matches the first private key component; if the verification parameter is different from the first data, 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 parameter with the corresponding data to obtain a matching result.

[0016] In a third aspect, some embodiments of the present application provide a device for proving the possession of a private key component in collaborative signature. The device is applied to a first terminal in a collaborative signature system, and the collaborative signature system further 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, configured to determine data to be verified based on key parameters, where 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; and a first sending module, 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.

[0017] Fourth aspect, some embodiments of the present application provide a device for proving the holding of a private key component in collaborative signature. The device is applied to a second terminal in a collaborative signature system, and 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 the private key in the collaborative signature system; the device includes: a second receiving module, configured to receive the data to be verified sent by the first terminal, where 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, configured to determine a verification parameter based on the second private key component and the data to be verified; a verification result output module, configured to confirm whether the second private key component matches the first private key component according to the verification parameter and the data to be verified.

[0018] Fifth aspect, some embodiments of the present application provide a computer-readable storage medium, on which a computer program is stored, and when the program is executed by a processor, the method described in any embodiment of the first aspect can be implemented.

[0019] Sixth aspect, some embodiments of the present application provide an electronic device, including a memory, a processor, and a computer program stored on the memory and executable on the processor, where when the processor executes the program, the method described in any embodiment of the first aspect can be implemented.

[0020] Seventh aspect, some embodiments of the present application provide a computer program product, where the computer program product includes a computer program, and when the computer program is executed by a processor, the method described in any embodiment of the first aspect can be implemented. Description of the Drawings

[0021] To more clearly illustrate the technical solutions of some embodiments of the present application, the drawings required for some embodiments of the present application will be briefly introduced below. It should be understood that the following drawings only show some embodiments of the present application and should not be regarded as limiting the scope. For those of ordinary skill in the art, other related drawings can be obtained based on these drawings without creative efforts.

[0022] Figure 1 It is a system diagram of proving the holding of a private key component in collaborative signature provided by some embodiments of the present application; Figure 2 It is one of the method flowcharts of proving the holding of a private key component in collaborative signature provided by some embodiments of the present application; Figure 3 It is another method flowchart of proving the holding of a private key component in collaborative signature provided by some embodiments of the present application; Figure 4 The third flowchart of the method for proving the possession of the private key component in the collaborative signature provided by some embodiments of the present application; Figure 5 The first block diagram of the device for proving the possession of the private key component in the collaborative signature provided by some embodiments of the present application; Figure 6 The second block diagram of the device for proving the possession of the private key component in the collaborative signature provided by some embodiments of the present application; Figure 7 A schematic diagram of an electronic device provided by some embodiments of the present application. Detailed implementation manners

[0023] Next, the technical solutions in some embodiments of the present application will be described with reference to the accompanying drawings in some embodiments of the present application.

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

[0025] In the related art, the process of collaborative decryption of the SM2 algorithm is given, and the client and the server execute decryption according to the specified process. In these collaborative decryption processes, generally one party (client / server) is designated as the initiator of the decryption process, and the other party is the collaborator of the decryption process. In the collaborative decryption process, the client and the server are peer-to-peer, and either of them can be the initiator.

[0026] Under normal circumstances, one of the collaborating parties is responsible for obtaining the ciphertext of business data. The other collaborating party cannot determine whether the received elliptic curve points come from a qualified business data ciphertext. Therefore, establishing a trust relationship between the two collaborating parties is crucial for protecting the security of private key components. A typical attack scenario is to achieve cross-ciphertext decryption attacks by replacing random elliptic curve points. A malicious client can replace the elliptic curve points by sending a constructed false ciphertext or replacing a valid ciphertext with another valid ciphertext (which may correspond to another electronic document), resulting in the attacker being able to decrypt other associated ciphertexts in the collaborative decryption process. In the prior art, methods such as username / password are generally used to authenticate the identity of the mobile terminal. For example, the mobile terminal holds a device identifier DevID, and then based on the password authentication protocol, it is confirmed that the device is trusted. However, this means of establishing a trust relationship relies on additional authentication factors and cannot directly confirm the trust relationship between the two collaborating parties. Or establish a TLS / SSL encrypted communication channel, etc. However, the TLS handshake requires multiple round-trip communications, and multiple rounds of interaction for collaborative signature / decryption may significantly increase the total latency; the symmetric encryption / asymmetric encryption operations of TLS will consume CPU resources, resulting in computational resource consumption. In addition, TLS relies on the CA system, which conflicts with the decentralized trust model of collaborative technology. If the CA is compromised, the TLS channel may be subject to man-in-the-middle attacks, and the distributed verification of the collaborative technology itself fails.

[0027] In view of this, some embodiments of the present application provide a method for proving the possession of private key components in collaborative signature. This method enhances the security of collaborative signature or decryption and reduces attacks by proving that the first terminal and the second terminal in the collaborative signature system hold matching private key components. At the same time, before performing 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 the cryptographic protocol with malicious participants, thereby preventing related malicious attacks.

[0028] The following combines the attached Figure 1 Exemplarily elaborate on the overall composition structure of the system for proving the possession of private key components in collaborative signature (or referred to as the collaborative signature system) provided by some embodiments of the present application.

[0029] As Figure 1 shown, some embodiments of the present application provide a system diagram for proving the possession of private key components in collaborative signature. The system for proving the possession of private key components in collaborative signature includes a first terminal 100 and a second terminal 200. Among them, 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). When verifying the proof of holding of the private key component, the first terminal 100 can calculate relevant key parameters to obtain the data to be verified, and send the data to be verified to the second terminal 200, so that the second terminal 200 can confirm whether the stored D1 and D2 match through the data to be verified.

[0030] It should be noted that the collaborative signature algorithm can be the national cryptographic SM2 algorithm, or the ECC algorithm, the SM9 algorithm, etc. The embodiments of the present application do not specifically limit the encryption and decryption algorithms here.

[0031] 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.

[0032] In practical applications, a one-way verification protocol can be performed from the client to the server to determine that the client and the server hold matching private key components; or a one-way verification protocol can be performed from the server to the client to determine that the server and the client hold matching private key components. Or, both parties can perform two-way verification: first, the client 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, first, the server determines that the client holds a matching private key component, and then the client determines that the server holds a matching private key component. Specifically, the verification method can be selected according to the actual scenario, and the embodiments of the present application do not specifically limit it here.

[0033] In addition, if there are more than two clients and servers storing a public key P in other application scenarios A corresponding to more than two private key components, at this time, after jointly calculating the data to be verified of different terminals, it can be determined that the stored private key components between more than two clients and servers match. The calculation principle of the data to be verified is the same as the principle of the method embodiments provided in the present application.

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

[0035] The following will exemplarily describe the implementation process of the proof of holding the private key component in the collaborative signature executed by the first terminal 100 provided by some embodiments of the present application in conjunction with the accompanying drawings. Figure 2

[0036] Figure 2 Figure 2

[0037]

[0038] S210. Determine the data to be verified based on the key parameters, where 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: the first data and the second data.

[0039] 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. Then, the client performs calculations on all or part of the parameters D1, R1, P A and G to obtain the first data Q1 and the second data U.

[0040] In some embodiments of the present application, S210 may include: performing calculations on the first private key component, the public key, the random number, and a base point with a prime order on the elliptic curve to obtain the first data; performing calculations on the random number and the base point to obtain the second data.

[0039] For example, in some embodiments of the present application, calculations are performed on D1, R1, P A and G to obtain Q1. The specific calculation formula is: Q1 = [D1R1](P A + G). Calculations are performed on R1 and G to obtain U, that is, U = [R1]G. It can be understood that the calculation methods of Q1 and U and the algorithms used can be flexibly adjusted according to the actual application scenario, and the embodiments of the present application are not limited thereto.

[0040] 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 the matching result.

[0041] 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 perform calculations and verifications in combination with D2 to confirm whether D1 and D2 of the client and the server match.

[0042] The following will exemplarily describe the implementation process of the server verifying the data to be verified in the method embodiments in Figure 2 to obtain the matching result.

[0043] Please refer to the attached Figure 3 , Figure 3 which is a flowchart of a method for proving the holding of a private key component in collaborative signature provided for some embodiments of the present application. The method for proving the holding of a private key component in collaborative signature may include: S310. Receive the data to be verified sent by the first terminal, where the data to be verified includes: first data and second data.

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

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

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

[0047] S330. Confirm whether the second private key component matches the first private key component according to the verification parameter and the data to be verified.

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

[0049] In some embodiments of the present application, S320 may include: calculating the verification parameter by performing calculations on the second private key component and the first data. S330 may include: if it is confirmed that the verification parameter is the same as the second data, then the second private key component matches the first private key component; if the verification parameter is different from the second data, then the second private key component does not match the first private key component.

[0050] For example, in some embodiments of the present application, the server calculates D2 and Q1 to obtain the verification parameter Q2, that is, Q2 = [D2]Q1. By comparing Q2 and U, it can be confirmed whether D1 of the client and D2 of the server match. That is: if Q2 = U, then D1 of the client and D2 of the server match; if Q2 ≠ U, then the private key proof fails, and the two parties have mismatched private key components.

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

[0052] 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 U. By comparing Q2' and Q1, it can be confirmed whether D1 of the client and D2 of the server match. That is: if Q2' = Q1, then D1 of the client and D2 of the server match; if Q2' ≠ Q1, then the private key proof fails and the two parties have mismatched private key components.

[0053] It should be noted that Q2 = U or Q2' = Q1 can prove that the private key components at both ends match, which is derived based on formula derivation. The following exemplarily elaborates the derivation process of Q2 = U: P A = [D1 -1 D2 -1 -1]G Q1 = [D1R1](P A + G)= [D1R1]([D1 -1 D2 -1 -1]G + G)= [D2 -1 R1]G U = [R1]G Q2 = [D2]Q1 = [D2][D2 -1 R1]G = [R1]G = U It can be seen that if D1 and D2 satisfy the calculation formula of P A , then the public key P A The corresponding private key d A Can deduce Q2 = U. It should be noted that the above formula can be flexibly adjusted, as long as the corresponding relationship between the private key d A Corresponding to the public key P A And Q2 = U or Q2' = Q1 remains unchanged.

[0054] The following takes the client and the server to verify whether each other holds a private key component that matches its own as an example to elaborate the implementation process of the private key component possession proof in the collaborative signature.

[0055] The following combines the attached Figure 4 Exemplarily elaborates the specific process of the private key component possession proof in the collaborative signature provided by some embodiments of the present application.

[0056] Please refer to the attached Figure 4 , Figure 4 which is a flowchart of a method for proving the possession of a private key component in collaborative signature provided for some embodiments of this application.

[0057] The above process will be described exemplarily below.

[0058] S401, the client generates a random number R1.

[0059] where R1 ∈ [1, n - 1] S402, the client calculates D1, R1, P A and G to obtain Q1 and U.

[0060] S403, the client sends Q1 and U to the server.

[0061] S404, the server calculates Q1 and D2 to obtain Q2.

[0062] S405, determine whether Q2 is equal to U. If so, execute S406; otherwise, execute S412.

[0063] S406, the server generates a random number R2.

[0064] where R2 ∈ [1, n - 1].

[0065] S407, the server calculates D2, R2, P A and G to obtain Q3 and V.

[0066] S408, the server sends Q3 and V to the client.

[0067] S409, the client calculates Q3 and D1 to obtain Q4.

[0068] S410, determine whether Q4 is equal to V. If so, execute S411; otherwise, execute S412.

[0069] S411, confirm that D1 of the client and D2 of the server match.

[0070] S412, feedback an error prompt.

[0071] where the error prompt indicates that the private key proof fails, the private key components of the two terminals do not match, and there is a security risk.

[0072] It can be understood that if S412 is directly executed from S405, it is the server that feedbacks the error prompt to the client; if S412 is executed from S410, it is the client that feedbacks the error prompt to the server.

[0073] It should be noted that the specific implementation processes of S401 to S412 can refer to the method embodiments provided above. To avoid repetition, the detailed descriptions are appropriately omitted here.

[0074] It can be seen that Figure 4 the client and the server in Figure 4 respectively generate random numbers and use the random numbers in the operation steps, so that the elliptic curve points output during each run of the private key component possession proof process are unique and can resist replay attacks. In practical applications, dedicated devices / chips can be used to generate true random numbers that meet the detection specifications. Based on the idea of "one-time pad", the security of the private key components during the private key component possession proof process can be ensured. In the implementation process of the private key component possession proof, 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 to the outside. In this scheme design, the discrete logarithm problem on the elliptic curve ensures the security of the private key components.

[0075] From some embodiments of the present application described above, it can be seen that in the interaction process between the two terminals in the embodiments of the present application, the intermediate results publicly disclosed by both parties do not appear the intermediate results used in the collaborative signature or protocol decryption process (such as temporary elliptic curve points, temporary variables publicly disclosed by linear equations, etc.), avoiding attackers from using these intermediate results to attack the collaborative signature and collaborative decryption protocols. In the private key component proof process proposed in the present invention, it can be confirmed that the peer holds the matching private key component, 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 the mobile terminal to initiate a collaborative process to the server, further improving the security of the system. In addition, after the 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.

[0076] Please refer to Figure 5 , Figure 5 which shows the block diagram of the device for proving the possession of the private key component in the collaborative signature provided by some embodiments of the present application. It should be understood that the device for proving the possession of the private key component in the collaborative signature corresponds to the above method embodiments and can execute each step involved in the above method embodiments. The specific functions of the device for proving the possession of the private key component in the collaborative signature can be seen in the above description. To avoid repetition, the detailed descriptions are appropriately omitted here.

[0077] Figure 5The device for proving the possession of a private key component in a collaborative signature includes at least one software function 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 a first private key component and a second private key component of a private key in the collaborative signature system; the device includes: a verification data calculation module 510, for determining 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; a first sending module 520, for sending 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.

[0078] Please refer to Figure 6 , Figure 6 The block diagram of the composition of the device for proving the possession of a private key component in a collaborative signature provided by some embodiments of the present application is shown. It should be understood that the device for proving the possession of a private key component in a collaborative signature corresponds to the above-mentioned method embodiment and can execute each step involved in the above-mentioned method embodiment. The specific functions of the device for proving the possession of a private key component in a collaborative signature can be found in the description above. To avoid repetition, the detailed description is appropriately omitted here.

[0079] Figure 6 The device for proving the possession of a private key component in a collaborative signature includes at least one software function 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.

[0080] Those skilled in the art can 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.

[0081] Some embodiments of the present application also provide a computer-readable storage medium, on which a computer program is stored. When the program is executed by a processor, the operations corresponding to any of the methods provided in the above embodiments can be implemented.

[0082] Some embodiments of the present application also provide a computer program product, which includes a computer program. When the computer program is executed by a processor, the operations corresponding to any of the methods provided in the above embodiments can be implemented.

[0083] As Figure 7 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 on the memory 710 and executable on the processor 720. When the processor 720 reads the program from the memory 710 through a bus 730 and executes the program, the method of any of the above embodiments can be implemented.

[0084] The processor 720 can process digital signals and can include various computing architectures. For example, 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, the processor 720 can be a microprocessor.

[0085] The memory 710 can be used to store instructions executed by the processor 720 or data related to the execution of the instructions. These instructions and / or data can include code for implementing some or all of the functions of one or more modules described in the embodiments of the present application. The processor 720 of the embodiments 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 a dynamic random access memory, a static random access memory, a flash memory, an optical memory, or other memories well known to those skilled in the art.

[0086] The above are only the embodiments of the present application and are not used to limit the protection scope of the present application. For those skilled in the art, the present application can have various changes and modifications. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application shall be included in the protection scope of the present application. It should be noted that similar reference numerals and letters indicate similar items in the following drawings. Therefore, once an item is defined in one drawing, it does not need to be further defined and explained in subsequent drawings.

[0087] As described above, it is only the specific implementation manner of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art within the technical scope disclosed by the present application can easily think of changes or substitutions, which should be covered within the protection scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims described above.

[0088] It should be noted that in this text, relational terms such as first and second are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any actual relationship or order between these entities or operations. Moreover, the term "comprising", "including" or any other variant thereof is intended to cover non-exclusive inclusion, so that a process, method, article or device comprising a series of elements not only includes those elements but also includes other elements not expressly listed, or further includes elements inherent to such process, method, article or device. Without further limitation, an element defined by the statement "comprising an..." does not exclude the existence of additional identical elements in the process, method, article or device comprising the said element.

Claims

1. A method for proving the holding of private key components in collaborative signature, characterized in that, The method is applied to a first terminal in a collaborative signature system, and the collaborative signature system further 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 the private key in the collaborative signature system; the method includes: Determine data to be verified based on key parameters, where 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; 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.

2. The method according to claim 1, characterized in that, 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, characterized in that The determining the data to be verified based on key parameters includes: Perform calculations on the first private key component, the public key, the random number, and a base point of an elliptic curve with a prime order to obtain the first data; Perform calculations on the random number and the base point to obtain the second data.

4. A method for proving the possession of private key components in collaborative signature, characterized in that, The method is applied to a second terminal in a collaborative signature system, and 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 the private key in the collaborative signature system; the method includes: Receive the data to be verified sent by the first terminal, where the data to be verified is obtained by the method according to any one of claims 1-3; the data to be verified includes: first data and second data; Determine a verification parameter based on the second private key component and the data to be verified; Confirm whether the second private key component matches the first private key component according to the verification parameter and the data to be verified.

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. The method according to claim 4 or 5, characterized in that, The determining the verification parameter based on the second private key component and the data to be verified includes: Perform calculations on the second private key component and the first data to obtain the verification parameter; The confirming whether the second private key component matches the first private key component according to the verification parameter and the data to be verified includes: If it is confirmed that the verification parameter is the same as the second data, then the second private key component matches the first private key component; If the verification parameter is different from the second data, then the second private key component does not match the first private key component.

7. The method according to claim 4 or 5, characterized in that, The determining the verification parameter based on the second private key component and the data to be verified includes: Perform calculations on the second private key component and the second data to obtain the verification parameter; The confirming whether the second private key component matches the first private key component according to the verification parameter and the data to be verified includes: If it is confirmed that the verification parameter is the same as the first data, then the second private key component matches the first private key component; If the verification parameter is different from the first data, the second private key component does not match the first private key component.

8. An apparatus for proving the possession of a private key component in collaborative signature, characterized in that, The device is applied to a first terminal in a collaborative signature system, and the collaborative signature system further 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, configured to determine data to be verified based on key parameters, where 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, 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.

9. An apparatus for proving the possession of a private key component in collaborative signature, characterized in that, The device is applied to a second terminal in a collaborative signature system, and the collaborative signature system further 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 device includes: A second receiving module, configured to receive the data to be verified sent by the first terminal, where the data to be verified is obtained by the method according to any one of claims 1-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, configured to confirm whether the second private key component matches the first private key component according to the verification parameter and the data to be verified.

10. An electronic device, characterized in that, It includes a memory, a processor, and a computer program stored on the memory and running on the processor, where the computer program, when run by the processor, executes the method according to any one of claims 1-7.

Images