TY - JOUR
AU1 - Tan, Liang
AU2 - Shang, Xinglin
AU3 - Zou, Liping
AU4 - Yang, Hekun
AU5 - Wen, Yi
AU6 - Liu, Zhongzhu
AB - Introduction With the rapid development of mobile Internet, the owners of mobile smart devices are increasing, and device owners can use their mobile devices to communicate with each other anytime and anywhere, and mobile devices have been fully integrated into the production life of society. According to real-time data from GSMA intelligence, as of the end of 2019, there are currently more than 5.2 billion unique owners of mobile devices worldwide (i.e., more than 67% of the world’s population has a mobile device), and this number is forecast to increase to 5.8 billion by the end of 2025, accounting for 70% of the world’s population [1]. Nowadays, it is very common for users to use mobile devices to conduct financial, securities and other transactions, and it has become particularly important to ensure the security of sensitive user data and transaction processes [2–4]. Data signature is an important cryptographic technology for authentication of mobile device users and integrity protection of mobile device data, which can play an important role in protecting users’ sensitive data and transaction process security. However, the digital signature technology has extremely high requirements for the storage and management of the signature private key of the mobile device, mobile devices themselves have security risks such as easy loss or hijacking, and limited computing power, if the software module is used to save the signature private key to the local or smart chip [5], this simple device security deployment and open network connections make mobile devices extremely easy to become the target of network attacks [6, 7]. Once the mobile device is hacked and the signature private key is stolen, the hacker can pretend to be a user in banking, insurance, securities, transportation, postal, e-commerce, mobile communications and other industries to conduct transactions, causing huge economic losses to the user. Currently, there are two specific methods to solve this problem. One is the threshold signature scheme based on Shamir’s secret sharing, which splits the signature private key of a device among n participants when and only when there are more than a threshold t (t≤n) participants collaboratively recovering the complete private key and signing it with their respective private key slice [8]. The signature private key slice in this scheme is no longer stored and managed by a unique device but by n devices, thus it is more secure and trustworthy, and even if a hacker breaks one or m(m < t) of the devices and obtains their private key slice, it still cannot construct a legitimate signature. However, this scheme is difficult to apply to mobile terminals with limited computing and storage resources. In addition such threshold signature schemes [9–13] all require the participation of trusted centers and suffer from high communication computational cost, complex interaction, and too many communications. The second is the two-party co-signature scheme. The so-called two-party co-signature scheme refers to the co-signature scheme in which only 2 entities participate, usually one is a mobile terminal, and the other is a secure and trusted server. There are also some research results available. The two-party ECDSA signature scheme proposed by Ref. [14] in 2017 provides a good research direction for the subsequent work [14–16]. The literature [17–19] proposed a two-party co-signature protocol based on the SM2 algorithm. The Ref. [20] proposed a two-party co-signature scheme based on the SM2 algorithm, which gives a security model and a proof of security, with only one communication between the signing parties. The signature generated by the two-party co-signature scheme is no longer generated by the mobile terminal device alone, but is generated by the two parties together, which greatly increases the difficulty for hackers to construct a legal signature and improves the security and trustworthiness of the signature. However, the two-party co-signing scheme still has three problems: first, two-party co-signing is not flexible enough. It requires that the cooperating party must be secure and trustworthy, so that the constructed collaborative signature can ensure the identity authentication and data integrity of mobile users. second, the two-party co-signing security still needs to be improved. Once a hacker obtains the signature private key and collaborative identity of the mobile device as the initiator of the signature, it is able to construct a legitimate two-party collaborative signature. Third, the application scenarios of two-party collaborative signatures are limited, which cannot meet the application scenarios of multi-device collaborative signatures. For example, in e-government affairs, leaders at all levels need to approve and sign the same document from lower to higher levels. In e-commerce Multiple partners sign the same contract, and the order of signatures can be fixed or random, etc. To this end, this paper proposes a scalable multi-party collaborative signature scheme based on the SM2 algorithm. In this scheme, each participant generates a key pair, and any participant can initiate a signature, and multiple parties jointly participate in generating a valid signature and a group public key for signature verification, which can ensure that each participant cannot know the signature key other than their own during the signing process, and the original complete signature cannot be recovered by any missing user. The experimental results show that this scheme can not only construct a legitimate signature, but also the time for multiple participants to construct a signature is similar, and the signature verification can pass and the verification time is less than the original SM2 scheme. Moreover, it is more flexible, safer and more reliable, and is suitable for application scenarios of multi-device collaborative signature, which has great practical value in events that require the joint participation of multiple departments, such as document issuance, certificate issuance and auditing. This article is divided into 7 sections for introduction. Section 1 introduces the background and development of SM2 algorithm, Section 2 introduces the basics involved in SM2 algorithm, Section 3 introduces the model and objective of SM2 algorithm, Section 4 introduces the principle of SM2 multi-party collaborative signature scheme based on SM2, Section 5 analyzes the security of SM2 multi-party collaborative scheme, Section 6 introduces the experiments and results analysis of SM2 multi-party collaborative scheme. Section 7 concludes the scheme of this paper. Basic knowledge This section will introduce the basic knowledge of digital signature and collaborative computing involved in this article. The symbol descriptions of related parameters are as follows. In this paper, λ denotes the safety parameter and μ(λ) denotes a negligible function of λ. In addition, [*] denotes the dot product operation of elliptic curve and [−] denotes the dot subtraction operation of elliptic curve; ⊙ denotes the scalar multiplication homomorphism operation, that is, a⊙b denotes the plaintext corresponding to b does multiplication operation with a; ⊕ means addition homomorphic operation, that is, a⊕b means that the plaintext corresponding to a and the plaintext corresponding to b are added. Hv() is the hash algorithm with digest length v bits. Encpk() denotes the encryption operation of the Paillier scheme [21] under the homomorphic public key pk, and Decsk() denotes the decryption operation of the Paillier scheme [21] under the homomorphic private key sk. Definition 1. Fp is a finite field, p denotes the scale of the finite field, and p is an odd prime or a square power of 2. E denotes an elliptic curve over a finite field Fp, and choose a, b ∈ Fp as the parameters of the elliptic curve E, where the elliptic curve E(Fp) satisfies y2 = x3 + ax + bmodp and (4a3 + 27b2) mod p ≠ 0, and G is a point on the elliptic curve, that is, E(Fp) = {G|G ∈ E}∪{O}. A set formed by the addition operation of G as the generator point is called a group [22], the number of points in this group is called order n, where {O} is the point at infinity. SM2 digital signature According to the specification of “SM2 Elliptic Curve Public Key Cryptography Algorithm”, the definition of SM2 digital signature [23] is as follows: (1) Parameter initialization (Setup): Input security parameters k, generate elliptic curve parameters params = (p, a, b, G, n) and output. (2) Key generation (Key): Given the elliptic curve parameters params, select the random number dA as the user’s private key and calculate P = dA × G as the corresponding public key. Output the public-private key pair (P, dA). (3) Signature algorithm (Sign): Given the elliptic curve parameters params, the private key dA and the message m, the algorithm steps for generating the signature (r, s) are as follows: ① Calculate ZA = Hv(ENTL∥IDA∥a∥b|P∥pk), where IDA is the distinguishable identifier of the user, ENTL is the length of IDA, calculate M′ = ZA∥M; ② Calculate e = Hv(M′), and convert the text e to an integer, where Hv() is a one-way function; ③ Select the random number , calculate the elliptic curve point Q = k[*]G = (x1, y1), and convert the data type of x1 to an integer; ④ Calculate the signature r = (e + x1)mod n, if r = 0 or r + k = n, return ③; ⑤ Calculate the signature s = (1 + dA)−1(k − rdA)modn, if s = 0, return to ③; otherwise, output the signature result (r, s). (4) Signature verification (Verify): Given parameters params, public key P = dA[*]G, message m′ and signature (r′, s′), the steps of the verification algorithm are as follows. ① Respectively check whether r′, s′ ∈ [1, n − 1] is established, if not, the verification fails; ② Calculate M″ = Z∥M′, compute e′ = Hv(M′) and convert the data type of e′ to an integer; ③ Convert the data type of signature (r′, s′) to integer and calculate t = (r′ + s′) mod n. If t = 0 then the verification does not pass; otherwise, go to step ④; ④ Calculate the elliptic curve point and convert the data type of to an integer; ⑤ Calculate mod n, check whether R = r′ is established, and output 1 if the verification passes; otherwise output 0. Secure Multi-Party Computation Secure Multi-Party Computation (SMC) was first proposed by Prof. Yao in 1980 [24], which is mainly used to solve the personal privacy problem between participants who do not trust each other. Secure Multi-Party Computation means that neither a public random string nor complex distributed settings are required. Each participant can generate its own key pair completely independently without any auxiliary information to complete the computation, which is an effective method to solve the privacy computation problem between two or more participants with strong theoretical and practical significance. In this paper, the scheme consists of multiple participants each selecting their own key pairs and jointly completing the signatures without revealing their respective privacy information, and during the computation process, all participants cannot obtain any additional valid information except for knowing their respective input data (including the received data transmitted by others) and the returned data results. SM2 digital signature According to the specification of “SM2 Elliptic Curve Public Key Cryptography Algorithm”, the definition of SM2 digital signature [23] is as follows: (1) Parameter initialization (Setup): Input security parameters k, generate elliptic curve parameters params = (p, a, b, G, n) and output. (2) Key generation (Key): Given the elliptic curve parameters params, select the random number dA as the user’s private key and calculate P = dA × G as the corresponding public key. Output the public-private key pair (P, dA). (3) Signature algorithm (Sign): Given the elliptic curve parameters params, the private key dA and the message m, the algorithm steps for generating the signature (r, s) are as follows: ① Calculate ZA = Hv(ENTL∥IDA∥a∥b|P∥pk), where IDA is the distinguishable identifier of the user, ENTL is the length of IDA, calculate M′ = ZA∥M; ② Calculate e = Hv(M′), and convert the text e to an integer, where Hv() is a one-way function; ③ Select the random number , calculate the elliptic curve point Q = k[*]G = (x1, y1), and convert the data type of x1 to an integer; ④ Calculate the signature r = (e + x1)mod n, if r = 0 or r + k = n, return ③; ⑤ Calculate the signature s = (1 + dA)−1(k − rdA)modn, if s = 0, return to ③; otherwise, output the signature result (r, s). (4) Signature verification (Verify): Given parameters params, public key P = dA[*]G, message m′ and signature (r′, s′), the steps of the verification algorithm are as follows. ① Respectively check whether r′, s′ ∈ [1, n − 1] is established, if not, the verification fails; ② Calculate M″ = Z∥M′, compute e′ = Hv(M′) and convert the data type of e′ to an integer; ③ Convert the data type of signature (r′, s′) to integer and calculate t = (r′ + s′) mod n. If t = 0 then the verification does not pass; otherwise, go to step ④; ④ Calculate the elliptic curve point and convert the data type of to an integer; ⑤ Calculate mod n, check whether R = r′ is established, and output 1 if the verification passes; otherwise output 0. Secure Multi-Party Computation Secure Multi-Party Computation (SMC) was first proposed by Prof. Yao in 1980 [24], which is mainly used to solve the personal privacy problem between participants who do not trust each other. Secure Multi-Party Computation means that neither a public random string nor complex distributed settings are required. Each participant can generate its own key pair completely independently without any auxiliary information to complete the computation, which is an effective method to solve the privacy computation problem between two or more participants with strong theoretical and practical significance. In this paper, the scheme consists of multiple participants each selecting their own key pairs and jointly completing the signatures without revealing their respective privacy information, and during the computation process, all participants cannot obtain any additional valid information except for knowing their respective input data (including the received data transmitted by others) and the returned data results. Safety model and design goals Based on the co-signature described in the introduction, we construct the following application scenarios. Taking a customer’s loan application as an example, a bank has three-level administrative departments A, B, and C. When a customer makes a large loan in the bank, the approval process will be relatively strict, and two or more departments are often required to review the transaction documents level by level [25], and the specific steps for multi-level signing of transaction documents by multiple departments are as follows. 1) The customer initiates an application for a large loan with the bank. 2) First, the bank receives the application, and the third-level department C reviews the customer’s personal credit and other information, and if the basic information is legal, the transaction document will be signed for the first time. 3) Then, after receiving the transaction documents signed by the tertiary department, the secondary department B will conduct a valuation review on the client’s asset information, etc. If the review is approved, the transaction documents will be signed for the second time. 4) Finally, the Level 1 department summarizes and finally reviews all the information required by the customer, and if there is no problem, the transaction document will be signed for the third time. In the above application, which involves joint cooperation among 3 departments, more review steps and corresponding signatures may be required in practical application scenarios. Therefore, this section will detail the security model on which the digital signature is based and the ideal design goals of the scheme in this paper. The main goal of the digital signature algorithm security model is to ensure that the attacker cannot obtain the user’s private data even through multiple signature interactions. Safety model The scheme in this paper is based on the framework of the MPC security proof model. By constructing an analog protocol, using the interaction of the signature process, the security is regulated to the security proof of the original digital signature scheme [24, 26]. (1) Communication model. It is assumed that the system parameters (and the standard parameters of SM2) can be passed to all participants in an efficient and secure manner. In addition, there is a peer-to-peer channel connected to any 2 participants to carry the protocol interactions. (2) Multiple digital signature. Depending on the signature process, multiple digital signatures [27, 28] are classified into sequential and broadcast multiple signatures. Sequential multi-signature means that the message sender specifies the order of signing the message, and then sends the message to be signed to the first signing member. After each signing member receives the message, it first verifies the validity of the previous signing member’s partial signature on the message, and if it is valid, it continues to sign and sends the generated partial signature to the next signing member; if the signature is invalid, it refuses to continue signing the received message and terminates the whole signing process. Until the last signing member completes the partial signature of the message, that is, the sequential multi-signature is completed [29]. In this paper, the key generation and co-signing parts of the scheme involve chain calculation data, so the concept of multiple digital signatures is used to complete the chain calculation of data. (3) Safety model. The security model of the digital signature algorithm contains challenger and adversary. The main attack on the digital signature scheme is forging the signature. If adversary is unable to forge a digital signature after several attacks, the signature constructed by challenger is considered to be secure. Definition 2. A signature algorithm (Setup, Key, Sign, Verify) is given in the digital signature algorithm attack game. Challenger runs the Setup and Key algorithms and exposes the generated system parameters params and the verifying public key P. Adversary obtains the parameters and initiates n (n is large enough) signature training to challenger. That is, the input message sequence {M1, M2, …, Mn} requires challenger to give a legitimate digital signature {δ1, δ2, …, δn}. After n times of signature training, adversary is able to construct a valid signature message pair (M*, δ*) satisfying the condition M* ≠ {M1, M2, …, Mn} and Verify(M*, δ*) = 1. It is considered that the adversary successfully forged the signature, that is, the signature constructed by the challenger is not secure, and the event is called Event_attack [2]and the Event_attack event satisfies the Eq (1). (1) Conversely, if all signature message pairs (M*, δ*) constructed by adversary cannot satisfy the condition M* ∉ {M1, M2, ⋯, Mn} and Verify(M*, δ*) = 1, then adversary is considered unable to forge a signature and this event is said to be a safety model of Event_safe, and the Event_safe event satisfies Eq (2). (2) Design goals The existing scheme enables multiple users or multiple devices U1, U2, …, Um to jointly complete a digital signature and satisfy a security model, where m>2 and any legal member of the signature can be signature initiator. In this model, participants in collaborative signatures must meet the following conditions. (1) The public keys of all participant key pairs are made public before participating in co-signing, and each participant has a unique index number for identity identification. (2) The public key values of all participants should be different, and even if the attacker and the participants have the same public key, they still correspond to multiple different private key values, which is guaranteed by the difficulty of solving the discrete logarithm problem on the elliptic curve. (3) Two steps are required to process the transmitted data during chain computing: ① encrypting the transmitted data with the next user’s public key value; ② digitally signing the encrypted data to be transmitted with the current user’s private key. (4) As long as the participant is a legal member of the collaborative signature and participates in the chain calculation of the public key value of the group, it is necessary to unconditionally cooperate with the signature when initiating the signature; (5) The attacker can corrupt up to m-1 participants, that is, at least one participant has not been corrupted, this scheme proves to be meaningful. The condition (1) is to distinguish whether it is a legal member of the collaborative signature, and the condition (2) can ensure that the encrypted data can only be decrypted by the only user who knows the corresponding private key, so as to ensure the confidentiality of the scheme; the private key in condition (3) decrypts the cryptographic data to guarantee the non-forgeability of the transmitted data, as well as the non-repudiation of the operation guaranteed by the digital signature verification, and from the multiple digital signatures in Section 3.1, it is known that all participants have and only one participation in the chain calculation, condition (4) can guarantee the correctness of the digital signature, and condition (5) can guarantee the integrity and practical significance of the multi-party co-signature scheme. Safety model The scheme in this paper is based on the framework of the MPC security proof model. By constructing an analog protocol, using the interaction of the signature process, the security is regulated to the security proof of the original digital signature scheme [24, 26]. (1) Communication model. It is assumed that the system parameters (and the standard parameters of SM2) can be passed to all participants in an efficient and secure manner. In addition, there is a peer-to-peer channel connected to any 2 participants to carry the protocol interactions. (2) Multiple digital signature. Depending on the signature process, multiple digital signatures [27, 28] are classified into sequential and broadcast multiple signatures. Sequential multi-signature means that the message sender specifies the order of signing the message, and then sends the message to be signed to the first signing member. After each signing member receives the message, it first verifies the validity of the previous signing member’s partial signature on the message, and if it is valid, it continues to sign and sends the generated partial signature to the next signing member; if the signature is invalid, it refuses to continue signing the received message and terminates the whole signing process. Until the last signing member completes the partial signature of the message, that is, the sequential multi-signature is completed [29]. In this paper, the key generation and co-signing parts of the scheme involve chain calculation data, so the concept of multiple digital signatures is used to complete the chain calculation of data. (3) Safety model. The security model of the digital signature algorithm contains challenger and adversary. The main attack on the digital signature scheme is forging the signature. If adversary is unable to forge a digital signature after several attacks, the signature constructed by challenger is considered to be secure. Definition 2. A signature algorithm (Setup, Key, Sign, Verify) is given in the digital signature algorithm attack game. Challenger runs the Setup and Key algorithms and exposes the generated system parameters params and the verifying public key P. Adversary obtains the parameters and initiates n (n is large enough) signature training to challenger. That is, the input message sequence {M1, M2, …, Mn} requires challenger to give a legitimate digital signature {δ1, δ2, …, δn}. After n times of signature training, adversary is able to construct a valid signature message pair (M*, δ*) satisfying the condition M* ≠ {M1, M2, …, Mn} and Verify(M*, δ*) = 1. It is considered that the adversary successfully forged the signature, that is, the signature constructed by the challenger is not secure, and the event is called Event_attack [2]and the Event_attack event satisfies the Eq (1). (1) Conversely, if all signature message pairs (M*, δ*) constructed by adversary cannot satisfy the condition M* ∉ {M1, M2, ⋯, Mn} and Verify(M*, δ*) = 1, then adversary is considered unable to forge a signature and this event is said to be a safety model of Event_safe, and the Event_safe event satisfies Eq (2). (2) (1) Communication model. It is assumed that the system parameters (and the standard parameters of SM2) can be passed to all participants in an efficient and secure manner. In addition, there is a peer-to-peer channel connected to any 2 participants to carry the protocol interactions. (2) Multiple digital signature. Depending on the signature process, multiple digital signatures [27, 28] are classified into sequential and broadcast multiple signatures. Sequential multi-signature means that the message sender specifies the order of signing the message, and then sends the message to be signed to the first signing member. After each signing member receives the message, it first verifies the validity of the previous signing member’s partial signature on the message, and if it is valid, it continues to sign and sends the generated partial signature to the next signing member; if the signature is invalid, it refuses to continue signing the received message and terminates the whole signing process. Until the last signing member completes the partial signature of the message, that is, the sequential multi-signature is completed [29]. In this paper, the key generation and co-signing parts of the scheme involve chain calculation data, so the concept of multiple digital signatures is used to complete the chain calculation of data. (3) Safety model. The security model of the digital signature algorithm contains challenger and adversary. The main attack on the digital signature scheme is forging the signature. If adversary is unable to forge a digital signature after several attacks, the signature constructed by challenger is considered to be secure. Definition 2. A signature algorithm (Setup, Key, Sign, Verify) is given in the digital signature algorithm attack game. Challenger runs the Setup and Key algorithms and exposes the generated system parameters params and the verifying public key P. Adversary obtains the parameters and initiates n (n is large enough) signature training to challenger. That is, the input message sequence {M1, M2, …, Mn} requires challenger to give a legitimate digital signature {δ1, δ2, …, δn}. After n times of signature training, adversary is able to construct a valid signature message pair (M*, δ*) satisfying the condition M* ≠ {M1, M2, …, Mn} and Verify(M*, δ*) = 1. It is considered that the adversary successfully forged the signature, that is, the signature constructed by the challenger is not secure, and the event is called Event_attack [2]and the Event_attack event satisfies the Eq (1). (1) Conversely, if all signature message pairs (M*, δ*) constructed by adversary cannot satisfy the condition M* ∉ {M1, M2, ⋯, Mn} and Verify(M*, δ*) = 1, then adversary is considered unable to forge a signature and this event is said to be a safety model of Event_safe, and the Event_safe event satisfies Eq (2). (2) Design goals The existing scheme enables multiple users or multiple devices U1, U2, …, Um to jointly complete a digital signature and satisfy a security model, where m>2 and any legal member of the signature can be signature initiator. In this model, participants in collaborative signatures must meet the following conditions. (1) The public keys of all participant key pairs are made public before participating in co-signing, and each participant has a unique index number for identity identification. (2) The public key values of all participants should be different, and even if the attacker and the participants have the same public key, they still correspond to multiple different private key values, which is guaranteed by the difficulty of solving the discrete logarithm problem on the elliptic curve. (3) Two steps are required to process the transmitted data during chain computing: ① encrypting the transmitted data with the next user’s public key value; ② digitally signing the encrypted data to be transmitted with the current user’s private key. (4) As long as the participant is a legal member of the collaborative signature and participates in the chain calculation of the public key value of the group, it is necessary to unconditionally cooperate with the signature when initiating the signature; (5) The attacker can corrupt up to m-1 participants, that is, at least one participant has not been corrupted, this scheme proves to be meaningful. The condition (1) is to distinguish whether it is a legal member of the collaborative signature, and the condition (2) can ensure that the encrypted data can only be decrypted by the only user who knows the corresponding private key, so as to ensure the confidentiality of the scheme; the private key in condition (3) decrypts the cryptographic data to guarantee the non-forgeability of the transmitted data, as well as the non-repudiation of the operation guaranteed by the digital signature verification, and from the multiple digital signatures in Section 3.1, it is known that all participants have and only one participation in the chain calculation, condition (4) can guarantee the correctness of the digital signature, and condition (5) can guarantee the integrity and practical significance of the multi-party co-signature scheme. SM2-based multi-party co-signing scheme In the design scheme of this paper, the signature is completed jointly by m participants U1, U2, …, Um. This section will introduce in detail the SM2-based multi-party collaborative signature scheme and the specific algorithm implementation proposed in this paper. The multi-party co-signing scheme is divided into two parts: key generation and co-signing, in which the generation of the group public key P in the key generation protocol and the signature intermediate value D in the co-signing process need to use the idea of sequential multi-signing in Section 31 to complete the data transmission and computation, and the sequential computation here is only to ensure that all co-signing participants participate in the computation only once. In the multi-party co-signing scheme, the system parameters and elliptic curves of the SM2 signature scheme are not changed. For the system initialization part of SM2, refer to the specification of “SM2 Elliptic Curve Public Key Cryptography Algorithm”. Scheme design In this scheme, the parameter initialization and signature verification process are the same as the national standard SM2 algorithm, which makes the scheme more applicable and has more application scenarios. The multi-party collaborative signature scheme is jointly completed by m (m ≥ 3) participants. First, each of the m participants invokes a function to generate a key pair, and the m participants chain invoke the function to compute the public key P of the signature group. Then the participants jointly sign, and any participant can become the signature initiator, and the final signature result (r, s) is calculated by the signature initiator. The symbol descriptions of related parameters are as follows: elliptic curve parameters are represented as params = (p, a, b, G, n); Ui represents the i-th participant, di represents the private key of the participant Ui, and Pi denotes the public key of participant Ui, ki represents the random number of participant Ui, Ki represents the intermediate value of the public point calculated by participant Ui; D represents the intermediate value of the second part of the signature, P represents the group public key of the multi-party signature, and r is the first part of the signature, and s is the second part of the signature. The specific process is shown in Fig 1. Download: PPT PowerPoint slide PNG larger image TIFF original image Fig 1. Multi-party co-signature flow chart. https://doi.org/10.1371/journal.pone.0268245.g001 Key generation The SM2 key generation algorithm is jointly completed by m participants. No one can master the complete signature key, and enter the elliptic curve parameter params. The specific group public key generation process is shown below. (1) Parameter initialization of participants (Setup): Ui → {ki, di, Pi, Ki} Participant Ui chooses the private key random number di ∈ [1, n − 1], calculates the public key Pi = di[*]G, takes any random number ki, and then calculates the intermediate value Ki = ki/di for the public point calculation. (2) All participants jointly calculate the group public key (Key): {di, G}→{P(x, y)} The group public key P is calculated jointly using the participant’s private key di and the generator G. All participants are chain-calculated with the group public key point value, where the initial value of pk0 is the generator G. When the group public key P is chained, participant U1 encrypts the computed point value data pk1 using the public key of the next participant Ui: pk1′ = Encpk(pk1, Pi), and then digitally signs the encrypted pk1 using U1’s private key d1: δ = Sign(pk1, d1), and finally sends the encrypted data pk1′ and digital signature δ to the next participant Ui; when the next participant Ui receives the message, decrypts the encrypted data pk1′ using the private key di, and then verifies the digital signature using the encrypted plaintext data, and if the verification passes, proceeds to the next step of computation and sends the encrypted data and digital signature to the next participant. This process can be started from different participants, and the group public key is calculated several times, and the specific operation flow is shown in Fig 2. Download: PPT PowerPoint slide PNG larger image TIFF original image Fig 2. Key generation flow chart. https://doi.org/10.1371/journal.pone.0268245.g002 The specific steps are as follows: ① Participant U1 initializes the parameters, calculates pk1 = d1−1[*]pk0, and then sends the ciphertext data and digital signature of pk1 to participant U2. ② Participant U2 initializes the parameters, first decrypts the received data and verifies the signature. If the verification is passed, calculate pk2 = d2−1[*]pk1, and finally send the cip-hertext data and digital signature of pk2 to the participant U3; …… ⓜ Participant Um initializes parameters, first decrypts the received data and verifies the signature. If the verification is passed, then calculate pkm = dm−1[*]pkm−1, and the last participant Um calculates P = pkm[*]G and publish the group public key, where P = dm-1[*]pkm-1 − G = … = dm-1 dm-1-1…d1-1[*]G − G. Co-signature Any participant can initiate a signature collaboration request as the signature initiator Ux, where x ∈ [1, m], and the public point Q used in the multi-party collaborative signature is computed jointly by all participants, and all participants except the signature initiator Ux send the intermediate value Ki of the public point computation to the signature initiator. (1) All participants chained calculation of the second part of the signature intermediate value (SignD): {Di−1, di}→{Di} The signature initiator Ux selects the private value b ∈ [1, n − 1] and uses the private key dx to calculate the intermediate transmission value D1 = dx*D0; all participants except the signature initiator Ux chain compute the second part of the signature intermediate value using the private key di, where the initial value of D0 is the private value b, which is only known to the signature initiator Ux. This process starts with the signature initiator, and there is no sequence among chained computing users. The specific steps are as follows. ① Signature initiator Ux selects the private value D0 = b, calculates D1 = dx*D0, and then sends D1 to participant U1. ② Participant U1 uses the private key d1, calculates D2 = d1*D1, and then sends D2 to participant U2. …… ⓘ Participant Ui uses the private key di to calculate Di+1 = di*Di, and then sends Di+1 to the participant Ui+1, where i ∈ [1, m] and i ≠ x; ⓜ Participant Um uses the private key dm to calculate Dm+1 = dm*Dm, where D = Dm+1 = dm * Dm = … = dm dm − 1 … d1 * b, and then the last participant Um returns D to the signature initiator Ux. (2) Signature initiator Ux calculates the first part of the signature r (Sign_r): {Q, hash}→{r} ① Signature initiator Ux computes ZA = Hv(ENTL∥ IDA∥|a∥b∥P∥pk), where IDA is the user’s distinguishable identifier and ENTL is the length of IDA, and computes M′ = ZA∥M; ② Signature initiator Ux computes e = Hv(M′) and converts the text e to an integer, where Hv() is a one-way function; ③ Signature initiator Ux calculates the value K = (K1 + K2 + … + Km) mod n based on the data Ki sent by each participant, and then calculates the open point Q = K[*]G = (x1, y1) and converts the data type of x1 to an integer; ④ Calculate the signature r = (e + x1) mod n, if r = 0 or r + k = n, return ③. (3) The signature initiator Ux calculates the second part of the signature s (Sign_s): {K, r, Dm, b}→{s} ⑤ After the signature initiator Ux receives the intermediate value D of the second part of the signature, it uses the private value b, the self-calculated K value and the first part signature r value to calculate the second part signature s value. Among them, s = (K + r)*D/b. The specific operation process is shown in Fig 3. Download: PPT PowerPoint slide PNG larger image TIFF original image Fig 3. Multi-signature flow chart. https://doi.org/10.1371/journal.pone.0268245.g003 (4) Anyone can verify the signature result (r′, s′) (Verify): {P, M′, r, s}→{R == r} According to the verification algorithm of SM2 digital signature, only need to calculate the elliptic curve point value and the signature data value mod n in sequence, and finally verify whether R = r′ holds, and the specific verification steps of the signature verifier Ux are shown below. ① The verifier separately checks whether r′ ∈ [1, n − 1] and s′ ∈ [1, n − 1]are established, if not, the verification fails; ② Set M″ = ZA∥M′; compute e′ = Hv(M″) and convert the data type of e′ to an integer; ③ Convert the data types of r′, s′ to integers and calculate t = (r′ + s′) mod n. If t = 0, the verification fails; ④ Calculate the elliptic curve point and convert the data type of to an integer; ⑤ Calculate mod n and check whether R = r′ holds, if it does, the validation passes; otherwise, the validation fails. Verification process Based on the key generation and co-signing process, the correctness of the scheme can be analyzed. The elliptic curve parameters are known: coefficients a and b, modulus p, generator G, and order n. In this scheme, each participant Ui has private data private key di, random number ki, public data Pi, and non-private data Ki. The specific verification process is shown below. First, generate the group public key P according to the key generation protocol: (3) Then, calculate the first part of the signature intermediate value K and the public point Q, and the second part of the signature intermediate value D: (4) (5) (6) Finally, the signature (r, s) is generated according to the co-signature protocol rules: (7) Derive the verification formula for the SM2 digital signature algorithm. (8) From s′ = (K + r)*D/b − r, D = dm…d1*b, we can get: (9) From , we know that is equal to x1, and the final validation calculation value mod n is exactly the same as the signature value r = (e + x1) mod n. The validation relation R = r holds, and the signature verification passes. It can be seen that the correctness of the scheme is verified and this scheme is completely feasible. Scheme design In this scheme, the parameter initialization and signature verification process are the same as the national standard SM2 algorithm, which makes the scheme more applicable and has more application scenarios. The multi-party collaborative signature scheme is jointly completed by m (m ≥ 3) participants. First, each of the m participants invokes a function to generate a key pair, and the m participants chain invoke the function to compute the public key P of the signature group. Then the participants jointly sign, and any participant can become the signature initiator, and the final signature result (r, s) is calculated by the signature initiator. The symbol descriptions of related parameters are as follows: elliptic curve parameters are represented as params = (p, a, b, G, n); Ui represents the i-th participant, di represents the private key of the participant Ui, and Pi denotes the public key of participant Ui, ki represents the random number of participant Ui, Ki represents the intermediate value of the public point calculated by participant Ui; D represents the intermediate value of the second part of the signature, P represents the group public key of the multi-party signature, and r is the first part of the signature, and s is the second part of the signature. The specific process is shown in Fig 1. Download: PPT PowerPoint slide PNG larger image TIFF original image Fig 1. Multi-party co-signature flow chart. https://doi.org/10.1371/journal.pone.0268245.g001 Key generation The SM2 key generation algorithm is jointly completed by m participants. No one can master the complete signature key, and enter the elliptic curve parameter params. The specific group public key generation process is shown below. (1) Parameter initialization of participants (Setup): Ui → {ki, di, Pi, Ki} Participant Ui chooses the private key random number di ∈ [1, n − 1], calculates the public key Pi = di[*]G, takes any random number ki, and then calculates the intermediate value Ki = ki/di for the public point calculation. (2) All participants jointly calculate the group public key (Key): {di, G}→{P(x, y)} The group public key P is calculated jointly using the participant’s private key di and the generator G. All participants are chain-calculated with the group public key point value, where the initial value of pk0 is the generator G. When the group public key P is chained, participant U1 encrypts the computed point value data pk1 using the public key of the next participant Ui: pk1′ = Encpk(pk1, Pi), and then digitally signs the encrypted pk1 using U1’s private key d1: δ = Sign(pk1, d1), and finally sends the encrypted data pk1′ and digital signature δ to the next participant Ui; when the next participant Ui receives the message, decrypts the encrypted data pk1′ using the private key di, and then verifies the digital signature using the encrypted plaintext data, and if the verification passes, proceeds to the next step of computation and sends the encrypted data and digital signature to the next participant. This process can be started from different participants, and the group public key is calculated several times, and the specific operation flow is shown in Fig 2. Download: PPT PowerPoint slide PNG larger image TIFF original image Fig 2. Key generation flow chart. https://doi.org/10.1371/journal.pone.0268245.g002 The specific steps are as follows: ① Participant U1 initializes the parameters, calculates pk1 = d1−1[*]pk0, and then sends the ciphertext data and digital signature of pk1 to participant U2. ② Participant U2 initializes the parameters, first decrypts the received data and verifies the signature. If the verification is passed, calculate pk2 = d2−1[*]pk1, and finally send the cip-hertext data and digital signature of pk2 to the participant U3; …… ⓜ Participant Um initializes parameters, first decrypts the received data and verifies the signature. If the verification is passed, then calculate pkm = dm−1[*]pkm−1, and the last participant Um calculates P = pkm[*]G and publish the group public key, where P = dm-1[*]pkm-1 − G = … = dm-1 dm-1-1…d1-1[*]G − G. Co-signature Any participant can initiate a signature collaboration request as the signature initiator Ux, where x ∈ [1, m], and the public point Q used in the multi-party collaborative signature is computed jointly by all participants, and all participants except the signature initiator Ux send the intermediate value Ki of the public point computation to the signature initiator. (1) All participants chained calculation of the second part of the signature intermediate value (SignD): {Di−1, di}→{Di} The signature initiator Ux selects the private value b ∈ [1, n − 1] and uses the private key dx to calculate the intermediate transmission value D1 = dx*D0; all participants except the signature initiator Ux chain compute the second part of the signature intermediate value using the private key di, where the initial value of D0 is the private value b, which is only known to the signature initiator Ux. This process starts with the signature initiator, and there is no sequence among chained computing users. The specific steps are as follows. ① Signature initiator Ux selects the private value D0 = b, calculates D1 = dx*D0, and then sends D1 to participant U1. ② Participant U1 uses the private key d1, calculates D2 = d1*D1, and then sends D2 to participant U2. …… ⓘ Participant Ui uses the private key di to calculate Di+1 = di*Di, and then sends Di+1 to the participant Ui+1, where i ∈ [1, m] and i ≠ x; ⓜ Participant Um uses the private key dm to calculate Dm+1 = dm*Dm, where D = Dm+1 = dm * Dm = … = dm dm − 1 … d1 * b, and then the last participant Um returns D to the signature initiator Ux. (2) Signature initiator Ux calculates the first part of the signature r (Sign_r): {Q, hash}→{r} ① Signature initiator Ux computes ZA = Hv(ENTL∥ IDA∥|a∥b∥P∥pk), where IDA is the user’s distinguishable identifier and ENTL is the length of IDA, and computes M′ = ZA∥M; ② Signature initiator Ux computes e = Hv(M′) and converts the text e to an integer, where Hv() is a one-way function; ③ Signature initiator Ux calculates the value K = (K1 + K2 + … + Km) mod n based on the data Ki sent by each participant, and then calculates the open point Q = K[*]G = (x1, y1) and converts the data type of x1 to an integer; ④ Calculate the signature r = (e + x1) mod n, if r = 0 or r + k = n, return ③. (3) The signature initiator Ux calculates the second part of the signature s (Sign_s): {K, r, Dm, b}→{s} ⑤ After the signature initiator Ux receives the intermediate value D of the second part of the signature, it uses the private value b, the self-calculated K value and the first part signature r value to calculate the second part signature s value. Among them, s = (K + r)*D/b. The specific operation process is shown in Fig 3. Download: PPT PowerPoint slide PNG larger image TIFF original image Fig 3. Multi-signature flow chart. https://doi.org/10.1371/journal.pone.0268245.g003 (4) Anyone can verify the signature result (r′, s′) (Verify): {P, M′, r, s}→{R == r} According to the verification algorithm of SM2 digital signature, only need to calculate the elliptic curve point value and the signature data value mod n in sequence, and finally verify whether R = r′ holds, and the specific verification steps of the signature verifier Ux are shown below. ① The verifier separately checks whether r′ ∈ [1, n − 1] and s′ ∈ [1, n − 1]are established, if not, the verification fails; ② Set M″ = ZA∥M′; compute e′ = Hv(M″) and convert the data type of e′ to an integer; ③ Convert the data types of r′, s′ to integers and calculate t = (r′ + s′) mod n. If t = 0, the verification fails; ④ Calculate the elliptic curve point and convert the data type of to an integer; ⑤ Calculate mod n and check whether R = r′ holds, if it does, the validation passes; otherwise, the validation fails. Verification process Based on the key generation and co-signing process, the correctness of the scheme can be analyzed. The elliptic curve parameters are known: coefficients a and b, modulus p, generator G, and order n. In this scheme, each participant Ui has private data private key di, random number ki, public data Pi, and non-private data Ki. The specific verification process is shown below. First, generate the group public key P according to the key generation protocol: (3) Then, calculate the first part of the signature intermediate value K and the public point Q, and the second part of the signature intermediate value D: (4) (5) (6) Finally, the signature (r, s) is generated according to the co-signature protocol rules: (7) Derive the verification formula for the SM2 digital signature algorithm. (8) From s′ = (K + r)*D/b − r, D = dm…d1*b, we can get: (9) From , we know that is equal to x1, and the final validation calculation value mod n is exactly the same as the signature value r = (e + x1) mod n. The validation relation R = r holds, and the signature verification passes. It can be seen that the correctness of the scheme is verified and this scheme is completely feasible. Implementation of SM2-based multi-party co-signature scheme In the implementation of the multi-party co-signing scheme in this paper, the number of specific participants m is determined when a multi-party co-signing scenario is identified in a particular enterprise or department. The implementation of this scheme is divided into 2 main parts: key generation implementation and co-signing implementation. This section will mainly introduce the custom functions and implementation process related to the scheme in this paper, and the specific implementation principles of the scheme are described in Sections 4.2 and 4.3. Key generation implementation The key generation process of SM2 algorithm is mainly done by m participants, which mainly includes the initialization of the participants’ parameters and the generation of the public key of the signature group. Definition 3. SM2_User_init(): The main function of this function is to allow each user to obtain private data and use it by calling the interface SM2_User_init(). In practical applications, both the random number ki and the private key di are generated by a random number generator. This process will be implemented using the function SM2_User_init(Useruser[]), where the parameters transmitted are the single-user structure User, which contains the user identification uID, random number ki, private key di, public key Pi, and public point calculation value Ki. The input parameter of this function is null, the output parameter is the structure User, and the return value type is null. Definition 4. SM2_Gpubkey_gen(): The main function of this function is for each signature participant to chain call the function SM2_Gpubkey_gen(uID, di, pki−1, *pki) and generate the point value pkm, where the initial value of the signature group public key P is −G, and then call the function SM2_Point_add(pkm, *P) to generate the final signature group public key P = pkm − G. The input parameters of this function are user uID, user private key di, the previous user calculation point pki−1 (the initial value pk0 is the generator G), and the output parameter is the user calculation point pki; the return value type is int, and when the return value is 1, it means that the signature group public key is computed successfully, otherwise, the calculation fails. The implementation process of key generation is shown below. The key generation timing chart is shown in Fig 4. Download: PPT PowerPoint slide PNG larger image TIFF original image Fig 4. Key generation timing chart. https://doi.org/10.1371/journal.pone.0268245.g004 Co-signature implementation The SM2 co-signing process will be implemented in four parts in sequence, which mainly including the initialization of the public data, the calculation of the second part of the signature intermediate value D, the generation of the first part of the signature r, and the generation of the first part of the signature s. Definition 5. SM2_Group_init(): The main function of this function is to calculate the required public data, which includes the signature calculation value K and the public point Qxy, where Qxy will be used as the required value for the calculation of the first part of the signature r and K will be used as the required value for the calculation of the second part of the signature s. In this process, each participant calls the value Ki generated by the function SM2_User_init(), and sends the calculated value Ki of the public point to the signature initiator for implementation. The input parameters of this function are all the values Ki, the output parameters are the signature calculation value K and the public point Qxy, the return value type is int, when the return value is 1, it means that the signature calculation value and the public point value are successfully calculated, otherwise, The calculation fails. Definition 6. SM2_cor_signD(): The main function of this function is to let each signature participant chain calls the function SM2_cor_signD(uID, Di−1, di, *Di) and generate the intermediate value D calculated by the private key, and transmits the intermediate value D of the private key calculation obtained by the last participant calling the function SM2_cor_sign_D() to the signature initiator Ux. The input parameters of this function are the user uID, the previous user calculation point Di−1 (the initial value D0 is the calculation data of the signature initiator’s optional value b and the private key), the user private key di, the output parameter is the user calculation point Di, and the return value type is int. When the return value is 1, it means that the calculation of the intermediate value D of the private key is successful, otherwise, the calculation fails. Definition 7. SM2_cor_sign_r(): The main function of this function is to generate the first part of the signature r. This process takes the public point Qxy and the hash value of the message to be signed generated by the signature initiator Ux calling the SM2_Group_init() function as input data, and then uses the SM2_cor_sign_r() function to calculate the first part of the signature r. The input parameter of this function is the public point Qxy, the hash value of the message to be signed, and the output parameter is the first part of the signature value r. The return value type is int, and when the return value is 1, it means that the first part of the signature is calculated successfully, otherwise, the calculation fails. Definition 8. SM2_cor_sign_s(): the main function of this function is to generate the second part of the signature s. This procedure will call the SM2_cor_sign_r() function to calculate the value r, the value K generated by the SM2_Group_init() function, the calculated value D of the SM2_cor_sign_D() function, and the signature initiator’s self-selected value b as input data, and finally the second part of the signature s is calculated using the SM2_cor_sign_s() function. The input parameters of this function are the first part signature r, the signature calculation value K, the intermediate value D of the private key calculation, and the self-chosen value b of the signature initiator, and the output parameter is the second part signature value s. The return value type is int, and when the return value is 1, it means that the second part signature calculation is successful, otherwise, the calculation fails. The implementation process of the co-signature is shown below, and the message to be signed is M. The co-signature timing chart is shown in Fig 5. Download: PPT PowerPoint slide PNG larger image TIFF original image Fig 5. Co-signature timing chart. https://doi.org/10.1371/journal.pone.0268245.g005 Key generation implementation The key generation process of SM2 algorithm is mainly done by m participants, which mainly includes the initialization of the participants’ parameters and the generation of the public key of the signature group. Definition 3. SM2_User_init(): The main function of this function is to allow each user to obtain private data and use it by calling the interface SM2_User_init(). In practical applications, both the random number ki and the private key di are generated by a random number generator. This process will be implemented using the function SM2_User_init(Useruser[]), where the parameters transmitted are the single-user structure User, which contains the user identification uID, random number ki, private key di, public key Pi, and public point calculation value Ki. The input parameter of this function is null, the output parameter is the structure User, and the return value type is null. Definition 4. SM2_Gpubkey_gen(): The main function of this function is for each signature participant to chain call the function SM2_Gpubkey_gen(uID, di, pki−1, *pki) and generate the point value pkm, where the initial value of the signature group public key P is −G, and then call the function SM2_Point_add(pkm, *P) to generate the final signature group public key P = pkm − G. The input parameters of this function are user uID, user private key di, the previous user calculation point pki−1 (the initial value pk0 is the generator G), and the output parameter is the user calculation point pki; the return value type is int, and when the return value is 1, it means that the signature group public key is computed successfully, otherwise, the calculation fails. The implementation process of key generation is shown below. The key generation timing chart is shown in Fig 4. Download: PPT PowerPoint slide PNG larger image TIFF original image Fig 4. Key generation timing chart. https://doi.org/10.1371/journal.pone.0268245.g004 Co-signature implementation The SM2 co-signing process will be implemented in four parts in sequence, which mainly including the initialization of the public data, the calculation of the second part of the signature intermediate value D, the generation of the first part of the signature r, and the generation of the first part of the signature s. Definition 5. SM2_Group_init(): The main function of this function is to calculate the required public data, which includes the signature calculation value K and the public point Qxy, where Qxy will be used as the required value for the calculation of the first part of the signature r and K will be used as the required value for the calculation of the second part of the signature s. In this process, each participant calls the value Ki generated by the function SM2_User_init(), and sends the calculated value Ki of the public point to the signature initiator for implementation. The input parameters of this function are all the values Ki, the output parameters are the signature calculation value K and the public point Qxy, the return value type is int, when the return value is 1, it means that the signature calculation value and the public point value are successfully calculated, otherwise, The calculation fails. Definition 6. SM2_cor_signD(): The main function of this function is to let each signature participant chain calls the function SM2_cor_signD(uID, Di−1, di, *Di) and generate the intermediate value D calculated by the private key, and transmits the intermediate value D of the private key calculation obtained by the last participant calling the function SM2_cor_sign_D() to the signature initiator Ux. The input parameters of this function are the user uID, the previous user calculation point Di−1 (the initial value D0 is the calculation data of the signature initiator’s optional value b and the private key), the user private key di, the output parameter is the user calculation point Di, and the return value type is int. When the return value is 1, it means that the calculation of the intermediate value D of the private key is successful, otherwise, the calculation fails. Definition 7. SM2_cor_sign_r(): The main function of this function is to generate the first part of the signature r. This process takes the public point Qxy and the hash value of the message to be signed generated by the signature initiator Ux calling the SM2_Group_init() function as input data, and then uses the SM2_cor_sign_r() function to calculate the first part of the signature r. The input parameter of this function is the public point Qxy, the hash value of the message to be signed, and the output parameter is the first part of the signature value r. The return value type is int, and when the return value is 1, it means that the first part of the signature is calculated successfully, otherwise, the calculation fails. Definition 8. SM2_cor_sign_s(): the main function of this function is to generate the second part of the signature s. This procedure will call the SM2_cor_sign_r() function to calculate the value r, the value K generated by the SM2_Group_init() function, the calculated value D of the SM2_cor_sign_D() function, and the signature initiator’s self-selected value b as input data, and finally the second part of the signature s is calculated using the SM2_cor_sign_s() function. The input parameters of this function are the first part signature r, the signature calculation value K, the intermediate value D of the private key calculation, and the self-chosen value b of the signature initiator, and the output parameter is the second part signature value s. The return value type is int, and when the return value is 1, it means that the second part signature calculation is successful, otherwise, the calculation fails. The implementation process of the co-signature is shown below, and the message to be signed is M. The co-signature timing chart is shown in Fig 5. Download: PPT PowerPoint slide PNG larger image TIFF original image Fig 5. Co-signature timing chart. https://doi.org/10.1371/journal.pone.0268245.g005 Safety analysis In this section, the provable security based on the original SM2 digital signature scheme is used to analytically prove the security of the multi-party collaborative digital signature scheme designed in this paper. Definition 9. Assuming that the existence of the original SM2 signature scheme π is unforgeable under the selective message attack [30], if for any probabilistic polynomial-time adversary in the security model, there exists a negligible function μ such that for each security parameter λ, there is Pr[SignA,π(1λ) = 1]≤μ(λ), that is, the signature scheme SignA,π constructed by adversary after polynomial query, the probability that the signature verification result is 1 is still less than one The negligible function μ(λ), then this scheme is proved to be secure. The collaborative signature scheme is also known as the distributed signature generation method, and the output digital signature can be effectively verified by the original verification algorithm. Therefore, the existence of the collaborative signature scheme can also be defined as unforgeable. Definition 10. Assume that the existence of the SM2 multi-party co-signature scheme Π under the selected message attack is unforgeable, its safety factor is κ. If for any probabilistic polynomial-time adversary in the security model, adversary passes through the fake signature initiator or corrupting all participants except the signature initiator, there is still a negligible function μ such that for each security parameter κ, there is Pr[DisSignA,Π(1κ) = 1]≤μ(κ), the signature scheme DisSignA,Π constructed with joint participation of adversary has a probability of signature verification result of 1 less than a negligible function μ(κ), then the multi-party collaborative signature scheme is proved to be secure. Proof of corruption of signature initiator In the whole SM2 multi-party collaborative (at least three-party) digital signature process, adversary corrupts the server of one participant who is a legitimate member of the multi-party collaboration and controls this server to initiate the collaborative signature application and obtains multi-party data only during the participation in the collaborative signature process, at which time the multi-party collaborative scheme is similar to the two-party collaborative signature scheme, but the data obtained is the product of the private keys of multiple participants. Adversary acts as the signature initiator UA, and adversary tries to obtain the other party’s private information through simulator ζ to get hold of the corrupted party’s key to forge the signature attack on the original scheme. The specific simulation scheme is shown below. (1) Simulation key generation. ① The adversary UA initiates the calculation of the group public key P. The adversary UA calculates the point value pk1 several times for encryption and digital signature processing, and sends the encrypted data and digital signature δ1 to the next participant Ui. ② When the next participant Ui receives the ciphertext and digital signature, it verifies the ciphertext by digital signature and recalculates the data until the last user calculates and discloses the value of group public key P. Therefore, even if the adversary UA uses a different value point to participate in the calculation of the group public key point value P′, the two points and P′ on the elliptic curve are known, guaranteed by the elliptic curve discrete logarithm difficulty problem, this process still cannot obtain any private information about the private key dx in polynomial time. (2) Simulation of co-signature. ① The adversary UA initiates a co-signature request. The adversary UA chooses any private value b′∈[1, n − 1], chooses to use the private key random number to calculate the intermediate transmission value , and sends D1 to the next user for chain calculation, and the last participant calculates the intermediate value and returns it to the adversary UA, who finally obtains the product of other users’ private keys by the private value b′ and the private key random number as: . ② The adversary UA calculates the value of K and the value of the public point Q. The co-signing participants Ui send their respective calculated intermediate values Ki to the adversary UA, and the adversary UA receives Ki also cannot calculate its specific factorized random number ki value and private key di value, and the adversary UA finally obtains the valid data as the intermediate values of other participants: K1, …, Kx−1, Kx+1, … Km, and the sum of the median values of other participants . The calculated value K and the public point Q value are ultimately determined by the value of the private key ; ③ If the adversary UA uses the private key random number , product value , sum value and point value to calculate the value and public point value Q′ = K′[*]G, finally calculate the intermediate value and the signature value , s = (K′ + r′)*D′/b′ − r′. ④ Finally, the previous r′ and s′ are verified by any user. (10) From the verification results and simulated key generation, it is clear that the probability that the private key random number is equal to the original private key value dx is negligible, and the adversary UA uses the private key random number to sign, and the signature verification result fails, that is, Pr[DisSignA,Π(1κ) = 1]≤μ(κ) holds constantly. Therefore adversary UA corrupts a participant’s server counterfeit signature initiator to forge a signature fails. Proof of maximum corruption In the entire SM2 multi-party collaborative digital signature process, adversary corrupts the servers of as many collaborative legitimate members as possible (up to m-1 participants), at which point the multi-party collaborative signature scheme is equivalent to a two-party collaborative signature containing signature initiator U1 and collaborative participant UA, while adversary corrupts collaborative participant UA, which can be up to m-1 participants at this point, and adversary UA attempts to multiple signature tests to obtain the other party’s information and forge the signature. The specific simulation scheme is shown below. (1) Simulated key generation. ① The signature initiator U1 initiates the calculation of the group public key P. U1 encrypts and digitally signs the point value calculated by itself and sends the encrypted data of pk1 and the digital signature δ1 to the co-participant UA. ② When the corrupted participant UA receives the ciphertext and digital signature, UA only knows the generated meta point value G and received point value pk1 or the original group public key point value P and received point value pk1, and it is known that the two points on the elliptic curve cannot obtain the valid privacy information; UA continues the calculation by the private key random number and finally gets the group public key . Therefore, the adversary UA cannot obtain any valid information during the simulation key generation process. (2) Simulated co-signature. ① The signature initiator U1 initiates a co-signature request. The signature initiator U1 can choose the private value b ∈ [1, n − 1], and use the private key d1 to calculate the intermediate transmission value D1 = d1*b, and send D1 to the corrupt cooperative user UA for chain calculation. ② The corrupt party UA only participates in the calculation of the intermediate value D once during the signature process, and only obtains the transmission data D1 of the signature initiator, and calculates the signature r′ = e + Q′ − >x1′, s = (K′ + r′)*D′/b′ − r′; the point value Q′ is the public data, K′ and b′ are the data held by U1, so it is impossible to forge the signature s. From the simulated co-signature process, it is clear that the adversary UA cannot obtain valid information when impersonating a co-signature participant. Therefore, adversary fails to obtain information to forge signatures by corrupting the servers of multiple participants. Proof of corruption of signature initiator In the whole SM2 multi-party collaborative (at least three-party) digital signature process, adversary corrupts the server of one participant who is a legitimate member of the multi-party collaboration and controls this server to initiate the collaborative signature application and obtains multi-party data only during the participation in the collaborative signature process, at which time the multi-party collaborative scheme is similar to the two-party collaborative signature scheme, but the data obtained is the product of the private keys of multiple participants. Adversary acts as the signature initiator UA, and adversary tries to obtain the other party’s private information through simulator ζ to get hold of the corrupted party’s key to forge the signature attack on the original scheme. The specific simulation scheme is shown below. (1) Simulation key generation. ① The adversary UA initiates the calculation of the group public key P. The adversary UA calculates the point value pk1 several times for encryption and digital signature processing, and sends the encrypted data and digital signature δ1 to the next participant Ui. ② When the next participant Ui receives the ciphertext and digital signature, it verifies the ciphertext by digital signature and recalculates the data until the last user calculates and discloses the value of group public key P. Therefore, even if the adversary UA uses a different value point to participate in the calculation of the group public key point value P′, the two points and P′ on the elliptic curve are known, guaranteed by the elliptic curve discrete logarithm difficulty problem, this process still cannot obtain any private information about the private key dx in polynomial time. (2) Simulation of co-signature. ① The adversary UA initiates a co-signature request. The adversary UA chooses any private value b′∈[1, n − 1], chooses to use the private key random number to calculate the intermediate transmission value , and sends D1 to the next user for chain calculation, and the last participant calculates the intermediate value and returns it to the adversary UA, who finally obtains the product of other users’ private keys by the private value b′ and the private key random number as: . ② The adversary UA calculates the value of K and the value of the public point Q. The co-signing participants Ui send their respective calculated intermediate values Ki to the adversary UA, and the adversary UA receives Ki also cannot calculate its specific factorized random number ki value and private key di value, and the adversary UA finally obtains the valid data as the intermediate values of other participants: K1, …, Kx−1, Kx+1, … Km, and the sum of the median values of other participants . The calculated value K and the public point Q value are ultimately determined by the value of the private key ; ③ If the adversary UA uses the private key random number , product value , sum value and point value to calculate the value and public point value Q′ = K′[*]G, finally calculate the intermediate value and the signature value , s = (K′ + r′)*D′/b′ − r′. ④ Finally, the previous r′ and s′ are verified by any user. (10) From the verification results and simulated key generation, it is clear that the probability that the private key random number is equal to the original private key value dx is negligible, and the adversary UA uses the private key random number to sign, and the signature verification result fails, that is, Pr[DisSignA,Π(1κ) = 1]≤μ(κ) holds constantly. Therefore adversary UA corrupts a participant’s server counterfeit signature initiator to forge a signature fails. (1) Simulation key generation. ① The adversary UA initiates the calculation of the group public key P. The adversary UA calculates the point value pk1 several times for encryption and digital signature processing, and sends the encrypted data and digital signature δ1 to the next participant Ui. ② When the next participant Ui receives the ciphertext and digital signature, it verifies the ciphertext by digital signature and recalculates the data until the last user calculates and discloses the value of group public key P. Therefore, even if the adversary UA uses a different value point to participate in the calculation of the group public key point value P′, the two points and P′ on the elliptic curve are known, guaranteed by the elliptic curve discrete logarithm difficulty problem, this process still cannot obtain any private information about the private key dx in polynomial time. (2) Simulation of co-signature. ① The adversary UA initiates a co-signature request. The adversary UA chooses any private value b′∈[1, n − 1], chooses to use the private key random number to calculate the intermediate transmission value , and sends D1 to the next user for chain calculation, and the last participant calculates the intermediate value and returns it to the adversary UA, who finally obtains the product of other users’ private keys by the private value b′ and the private key random number as: . ② The adversary UA calculates the value of K and the value of the public point Q. The co-signing participants Ui send their respective calculated intermediate values Ki to the adversary UA, and the adversary UA receives Ki also cannot calculate its specific factorized random number ki value and private key di value, and the adversary UA finally obtains the valid data as the intermediate values of other participants: K1, …, Kx−1, Kx+1, … Km, and the sum of the median values of other participants . The calculated value K and the public point Q value are ultimately determined by the value of the private key ; ③ If the adversary UA uses the private key random number , product value , sum value and point value to calculate the value and public point value Q′ = K′[*]G, finally calculate the intermediate value and the signature value , s = (K′ + r′)*D′/b′ − r′. ④ Finally, the previous r′ and s′ are verified by any user. (10) From the verification results and simulated key generation, it is clear that the probability that the private key random number is equal to the original private key value dx is negligible, and the adversary UA uses the private key random number to sign, and the signature verification result fails, that is, Pr[DisSignA,Π(1κ) = 1]≤μ(κ) holds constantly. Therefore adversary UA corrupts a participant’s server counterfeit signature initiator to forge a signature fails. Proof of maximum corruption In the entire SM2 multi-party collaborative digital signature process, adversary corrupts the servers of as many collaborative legitimate members as possible (up to m-1 participants), at which point the multi-party collaborative signature scheme is equivalent to a two-party collaborative signature containing signature initiator U1 and collaborative participant UA, while adversary corrupts collaborative participant UA, which can be up to m-1 participants at this point, and adversary UA attempts to multiple signature tests to obtain the other party’s information and forge the signature. The specific simulation scheme is shown below. (1) Simulated key generation. ① The signature initiator U1 initiates the calculation of the group public key P. U1 encrypts and digitally signs the point value calculated by itself and sends the encrypted data of pk1 and the digital signature δ1 to the co-participant UA. ② When the corrupted participant UA receives the ciphertext and digital signature, UA only knows the generated meta point value G and received point value pk1 or the original group public key point value P and received point value pk1, and it is known that the two points on the elliptic curve cannot obtain the valid privacy information; UA continues the calculation by the private key random number and finally gets the group public key . Therefore, the adversary UA cannot obtain any valid information during the simulation key generation process. (2) Simulated co-signature. ① The signature initiator U1 initiates a co-signature request. The signature initiator U1 can choose the private value b ∈ [1, n − 1], and use the private key d1 to calculate the intermediate transmission value D1 = d1*b, and send D1 to the corrupt cooperative user UA for chain calculation. ② The corrupt party UA only participates in the calculation of the intermediate value D once during the signature process, and only obtains the transmission data D1 of the signature initiator, and calculates the signature r′ = e + Q′ − >x1′, s = (K′ + r′)*D′/b′ − r′; the point value Q′ is the public data, K′ and b′ are the data held by U1, so it is impossible to forge the signature s. From the simulated co-signature process, it is clear that the adversary UA cannot obtain valid information when impersonating a co-signature participant. Therefore, adversary fails to obtain information to forge signatures by corrupting the servers of multiple participants. (1) Simulated key generation. ① The signature initiator U1 initiates the calculation of the group public key P. U1 encrypts and digitally signs the point value calculated by itself and sends the encrypted data of pk1 and the digital signature δ1 to the co-participant UA. ② When the corrupted participant UA receives the ciphertext and digital signature, UA only knows the generated meta point value G and received point value pk1 or the original group public key point value P and received point value pk1, and it is known that the two points on the elliptic curve cannot obtain the valid privacy information; UA continues the calculation by the private key random number and finally gets the group public key . Therefore, the adversary UA cannot obtain any valid information during the simulation key generation process. (2) Simulated co-signature. ① The signature initiator U1 initiates a co-signature request. The signature initiator U1 can choose the private value b ∈ [1, n − 1], and use the private key d1 to calculate the intermediate transmission value D1 = d1*b, and send D1 to the corrupt cooperative user UA for chain calculation. ② The corrupt party UA only participates in the calculation of the intermediate value D once during the signature process, and only obtains the transmission data D1 of the signature initiator, and calculates the signature r′ = e + Q′ − >x1′, s = (K′ + r′)*D′/b′ − r′; the point value Q′ is the public data, K′ and b′ are the data held by U1, so it is impossible to forge the signature s. From the simulated co-signature process, it is clear that the adversary UA cannot obtain valid information when impersonating a co-signature participant. Therefore, adversary fails to obtain information to forge signatures by corrupting the servers of multiple participants. Experimental results and performance analysis In this section, we analyze and evaluate the signature and verification results of the multi-party collaborative signature scheme with different number of participants for the multi-party collaborative signature scheme proposed in Section 4.3, and compare the implementation and verification runtime of the original SM2 scheme with different multi-party collaborative signatures. The implementation of the original SM2 scheme and the multi-party collaborative digital signature algorithm are shown in Algorithm 1 and Algorithm 2, respectively. Download: PPT PowerPoint slide PNG larger image TIFF original image Experimental environment In this paper, we construct a model based on the multi-party co-signing scheme of SM2 algorithm. The experimental PC operating system is win10 operating system, the processor is Intel(R) Core(TM) i7-5500U CPU @ 2.40GHz 2.39GHz, 8G RAM; the large integer library gmp-6.2.0 is selected for implementation; the main programming language is C; the platform used to implement the algorithm is Visual Studio 2019. In addition, the system parameters are the elliptic curve parameters recommended by the State Secret. Experimental results Anti-forgery attacks. Multi-party co-signing is inherently resistant to forgery attacks, During the signature process, the complete private key does not appear in the memory of any party, eliminating the risk of forgery of digital signatures due to private key leakage, and the complete signature cannot be generated without the participation of any party after the public key of the co-signing group is determined. In addition, the identity of each user is legitimate at the time of signature group public key generation, even if the forger forges the signature by impersonating a node in the signature process, the forged signature cannot pass the verification in the final signature verification process with the participation of the group public key, so the forger fails to forge the signature. Taking 3-party collaboration as an example, assume that the authenticated collaborative participants are userA{dA, PA}, userB{dB, PB}, userC{dC, PC}, and the generated legitimate group public key is . The counterfeiter forgerA attacks the participant userA, and forges information such as the same identity IDA, the same public key PA (the private key is different dX) and other information. The steps for forging the signature are as follows: (1) Forger forgerA requests participant chain to calculate the second part of the signature intermediate value (Sign_D) ① ForgerA initiates a signature, first selects the private value D0 = b, calculates D1 = dx*D0, and then sends D1 to the participant userB; ② The participant userB uses the private key dB to calculate D2 = dB*D1, and then sends D2 to the participant userC; ③ The participant userC uses the private key dC to calculate D3 = dC*D2, where D = D3 = dC*dB*dX*b, and finally returns D to the signature initiator forgerA. (2) The forger forgerA calculates the first part of the signature r (Sign_r) ① ForgerA calculates ZA = Hv(ENTL∥IDA∥a∥b∥P∥pk), and calculates M’ = ZA∥M; ② The counterfeiter forgerA calculates e = Hv(M′), and converts the text e to an integer, where Hv() is a one-way function; ③ The forger forgerA calculates the value K = (KX + KA + KB)modn based on the data Ki sent by each participant, where KX = kX/dX, and then calculates the public point Q = K[*]G = (x1, y1), and convert the data type of x1 to integer. ④ Calculate the signature r = (e+x1) mod n, and return ③ if r = 0 or r+k = n. (3) Forger forgerA calculates the second part of signature s (Sign_s) ⑤ ForgerA uses the signature intermediate value D, private value b, self-calculated K value and the first part of the signature r value to calculate the second part of the signature s value, where s = (K + r)*D/b − r = (K + r)*dC dB dX − r. (4) Verification of the forged signature result (r′, s′) Verify the forged digital signature by deriving the verification formula , where , t = (r′ + s′)modn. The detailed verification steps of the signature are described in Section 4.4. (11) It can be seen from the verification result of the forged signature that Q’ ≠ Q, , then R ≠ r’, that is, the verification fails and the forged signature fails. Feasibility and flexibility validation. In order to verify the feasibility and flexibility of this solution, we choose a specific application scenario: an enterprise produces an important product for a large number of users, and needs qualified manufacturers of semi-finished products, and qualified semi-finished products need qualified manufacturers of components, qualified parts manufacturers need qualified raw material suppliers to provide, which forms a supply chain. In order to ensure that the quality of the final product is recognized and accepted by the user, the company needs the company in the supply chain to collaborate to sign a product quality commitment to users, and the user can verify the signature to trust the quality of the product. Because once the user’s verification is passed, it means that the supply chain of the product is trustworthy. In response to this scenario, we separately set the private key and random number of the SM2 digital signature, and the private keys and random numbers of multiple companies in the industry chain. In order to facilitate the experiment, we take the same values for the private keys and random numbers of multiple enterprises in the industry chain as the original SM2 digital signature scheme: dA = “0x128B2FA8 BD433C6C 068C8D80 3DFF7979 2A519A55 171B1B65 0C23661D 15897263”; k = “0x6CB28D99 385C175C 94F94E93 4817663F C176D925 DD72B727 260DBAAE 1FB2F96F”. (1) The plaintext message digest of the original SM2 digital signature scheme uses the SM3 algorithm to calculate the hash e(Hash) and the public key P(X, Y), and the digital signature (r, s) and signature verification results are shown in Fig 6. Download: PPT PowerPoint slide PNG larger image TIFF original image Fig 6. Original SM2 digital signature and verification data. https://doi.org/10.1371/journal.pone.0268245.g006 (2) The SM3 algorithm is used to calculate the hash e(Hash) and group public key P(X, Y), as well as the digital signature (r, s) and signature verification results for the plaintext “message digest” of the SM2 industry chain multi-enterprise collaborative digital signature scheme. The results of co-signatures are shown in Figs 7–9 for 3, 8, and 23 parties. Download: PPT PowerPoint slide PNG larger image TIFF original image Fig 7. 3-party co-digital signature and verification data. https://doi.org/10.1371/journal.pone.0268245.g007 Download: PPT PowerPoint slide PNG larger image TIFF original image Fig 8. 8-party co-digital signature and verification data. https://doi.org/10.1371/journal.pone.0268245.g008 Download: PPT PowerPoint slide PNG larger image TIFF original image Fig 9. 23-party co-digital signature and verification data. https://doi.org/10.1371/journal.pone.0268245.g009 From the above experimental results, it can be seen that this scheme has strong flexibility, and the participants of the supply chain can be any n parties such as 3 parties or 8 parties to participate in the collaborative signature, which can meet the requirements of any multi-party hierarchical evaluation of the same document in electronic transactions, making the multi-party collaborative signature scheme have stronger applicability. In addition, this scheme can obtain legal signature results for different number of supply chain participants and the verification result is correct, which shows the correctness and feasibility of this scheme. In addition, for the n-party co-signing scheme, unless the hacker obtains the signature key of the n − 1 signer, the legitimate signature cannot be forged, so the multi-party co-signing scheme in this paper also has sufficient security. Performance analysis. For the differences caused by running in different time periods in the native environment, firstly, the original SM2 scheme will be carried out several times with multiple co-signers at the same time, and then the running time of multiple signatures of the original SM2 scheme (the difference in the values taken should not be too large) will be taken, and finally the average value will be used as the standard value for floating values, and the running time of multiple co-signers in the corresponding range of floating values will be selected. For different parties, 100 tests were conducted, and the number of multiparty co-signers was taken as 3, 8, 23, etc., and then the average value of the running time was calculated. The average running time of the digital signature interface and signature verification interface of the original SM2 scheme and the multi-party collaboration algorithm are shown in Fig 10. Download: PPT PowerPoint slide PNG larger image TIFF original image Fig 10. Average runtime of SM2 scheme and multi-party co-digital signature and signature verification. https://doi.org/10.1371/journal.pone.0268245.g010 The above data counts the average running time of the digital signature interface of the original SM2 scheme and the multi-party collaboration algorithm (that is, Algorithm 1 and Algorithm 2), and after running Algorithm 1 and Algorithm 2 several times simultaneously, changing only the number of supply chain participants in the collaborative signature each time, and finally taking the running time of the original SM2 signature as the standard value to take the running time of multiple interfaces and calculate the average value. From the above statistical results, it can be seen that there is no additional burden on the performance of the signature scheme when increasing the number of multi-signers, because the signature time of Algorithm 2 here is only the interface time for the final calculation of the signature result by the tested signature initiator, and the number of supply chain participants does not correlate with the signature time, so the signature times of Algorithm 1 and Algorithm 2 are almost the same. In addition, for the results of multi-party co-signing, signature verification has been performed using the standard SM2 verification interface, and the verification in Section 7.2.1 experimental results passed proving that multi-party co-signing is feasible, flexible and universally applicable to application scenarios such as multi-user and multi-device digital signatures. Thus, although there is a certain amount of computing time and data transmission time when calculating the intermediate values before the signature of this scheme, this scheme is still highly feasible and has wide application prospects. Experimental environment In this paper, we construct a model based on the multi-party co-signing scheme of SM2 algorithm. The experimental PC operating system is win10 operating system, the processor is Intel(R) Core(TM) i7-5500U CPU @ 2.40GHz 2.39GHz, 8G RAM; the large integer library gmp-6.2.0 is selected for implementation; the main programming language is C; the platform used to implement the algorithm is Visual Studio 2019. In addition, the system parameters are the elliptic curve parameters recommended by the State Secret. Experimental results Anti-forgery attacks. Multi-party co-signing is inherently resistant to forgery attacks, During the signature process, the complete private key does not appear in the memory of any party, eliminating the risk of forgery of digital signatures due to private key leakage, and the complete signature cannot be generated without the participation of any party after the public key of the co-signing group is determined. In addition, the identity of each user is legitimate at the time of signature group public key generation, even if the forger forges the signature by impersonating a node in the signature process, the forged signature cannot pass the verification in the final signature verification process with the participation of the group public key, so the forger fails to forge the signature. Taking 3-party collaboration as an example, assume that the authenticated collaborative participants are userA{dA, PA}, userB{dB, PB}, userC{dC, PC}, and the generated legitimate group public key is . The counterfeiter forgerA attacks the participant userA, and forges information such as the same identity IDA, the same public key PA (the private key is different dX) and other information. The steps for forging the signature are as follows: (1) Forger forgerA requests participant chain to calculate the second part of the signature intermediate value (Sign_D) ① ForgerA initiates a signature, first selects the private value D0 = b, calculates D1 = dx*D0, and then sends D1 to the participant userB; ② The participant userB uses the private key dB to calculate D2 = dB*D1, and then sends D2 to the participant userC; ③ The participant userC uses the private key dC to calculate D3 = dC*D2, where D = D3 = dC*dB*dX*b, and finally returns D to the signature initiator forgerA. (2) The forger forgerA calculates the first part of the signature r (Sign_r) ① ForgerA calculates ZA = Hv(ENTL∥IDA∥a∥b∥P∥pk), and calculates M’ = ZA∥M; ② The counterfeiter forgerA calculates e = Hv(M′), and converts the text e to an integer, where Hv() is a one-way function; ③ The forger forgerA calculates the value K = (KX + KA + KB)modn based on the data Ki sent by each participant, where KX = kX/dX, and then calculates the public point Q = K[*]G = (x1, y1), and convert the data type of x1 to integer. ④ Calculate the signature r = (e+x1) mod n, and return ③ if r = 0 or r+k = n. (3) Forger forgerA calculates the second part of signature s (Sign_s) ⑤ ForgerA uses the signature intermediate value D, private value b, self-calculated K value and the first part of the signature r value to calculate the second part of the signature s value, where s = (K + r)*D/b − r = (K + r)*dC dB dX − r. (4) Verification of the forged signature result (r′, s′) Verify the forged digital signature by deriving the verification formula , where , t = (r′ + s′)modn. The detailed verification steps of the signature are described in Section 4.4. (11) It can be seen from the verification result of the forged signature that Q’ ≠ Q, , then R ≠ r’, that is, the verification fails and the forged signature fails. Feasibility and flexibility validation. In order to verify the feasibility and flexibility of this solution, we choose a specific application scenario: an enterprise produces an important product for a large number of users, and needs qualified manufacturers of semi-finished products, and qualified semi-finished products need qualified manufacturers of components, qualified parts manufacturers need qualified raw material suppliers to provide, which forms a supply chain. In order to ensure that the quality of the final product is recognized and accepted by the user, the company needs the company in the supply chain to collaborate to sign a product quality commitment to users, and the user can verify the signature to trust the quality of the product. Because once the user’s verification is passed, it means that the supply chain of the product is trustworthy. In response to this scenario, we separately set the private key and random number of the SM2 digital signature, and the private keys and random numbers of multiple companies in the industry chain. In order to facilitate the experiment, we take the same values for the private keys and random numbers of multiple enterprises in the industry chain as the original SM2 digital signature scheme: dA = “0x128B2FA8 BD433C6C 068C8D80 3DFF7979 2A519A55 171B1B65 0C23661D 15897263”; k = “0x6CB28D99 385C175C 94F94E93 4817663F C176D925 DD72B727 260DBAAE 1FB2F96F”. (1) The plaintext message digest of the original SM2 digital signature scheme uses the SM3 algorithm to calculate the hash e(Hash) and the public key P(X, Y), and the digital signature (r, s) and signature verification results are shown in Fig 6. Download: PPT PowerPoint slide PNG larger image TIFF original image Fig 6. Original SM2 digital signature and verification data. https://doi.org/10.1371/journal.pone.0268245.g006 (2) The SM3 algorithm is used to calculate the hash e(Hash) and group public key P(X, Y), as well as the digital signature (r, s) and signature verification results for the plaintext “message digest” of the SM2 industry chain multi-enterprise collaborative digital signature scheme. The results of co-signatures are shown in Figs 7–9 for 3, 8, and 23 parties. Download: PPT PowerPoint slide PNG larger image TIFF original image Fig 7. 3-party co-digital signature and verification data. https://doi.org/10.1371/journal.pone.0268245.g007 Download: PPT PowerPoint slide PNG larger image TIFF original image Fig 8. 8-party co-digital signature and verification data. https://doi.org/10.1371/journal.pone.0268245.g008 Download: PPT PowerPoint slide PNG larger image TIFF original image Fig 9. 23-party co-digital signature and verification data. https://doi.org/10.1371/journal.pone.0268245.g009 From the above experimental results, it can be seen that this scheme has strong flexibility, and the participants of the supply chain can be any n parties such as 3 parties or 8 parties to participate in the collaborative signature, which can meet the requirements of any multi-party hierarchical evaluation of the same document in electronic transactions, making the multi-party collaborative signature scheme have stronger applicability. In addition, this scheme can obtain legal signature results for different number of supply chain participants and the verification result is correct, which shows the correctness and feasibility of this scheme. In addition, for the n-party co-signing scheme, unless the hacker obtains the signature key of the n − 1 signer, the legitimate signature cannot be forged, so the multi-party co-signing scheme in this paper also has sufficient security. Performance analysis. For the differences caused by running in different time periods in the native environment, firstly, the original SM2 scheme will be carried out several times with multiple co-signers at the same time, and then the running time of multiple signatures of the original SM2 scheme (the difference in the values taken should not be too large) will be taken, and finally the average value will be used as the standard value for floating values, and the running time of multiple co-signers in the corresponding range of floating values will be selected. For different parties, 100 tests were conducted, and the number of multiparty co-signers was taken as 3, 8, 23, etc., and then the average value of the running time was calculated. The average running time of the digital signature interface and signature verification interface of the original SM2 scheme and the multi-party collaboration algorithm are shown in Fig 10. Download: PPT PowerPoint slide PNG larger image TIFF original image Fig 10. Average runtime of SM2 scheme and multi-party co-digital signature and signature verification. https://doi.org/10.1371/journal.pone.0268245.g010 The above data counts the average running time of the digital signature interface of the original SM2 scheme and the multi-party collaboration algorithm (that is, Algorithm 1 and Algorithm 2), and after running Algorithm 1 and Algorithm 2 several times simultaneously, changing only the number of supply chain participants in the collaborative signature each time, and finally taking the running time of the original SM2 signature as the standard value to take the running time of multiple interfaces and calculate the average value. From the above statistical results, it can be seen that there is no additional burden on the performance of the signature scheme when increasing the number of multi-signers, because the signature time of Algorithm 2 here is only the interface time for the final calculation of the signature result by the tested signature initiator, and the number of supply chain participants does not correlate with the signature time, so the signature times of Algorithm 1 and Algorithm 2 are almost the same. In addition, for the results of multi-party co-signing, signature verification has been performed using the standard SM2 verification interface, and the verification in Section 7.2.1 experimental results passed proving that multi-party co-signing is feasible, flexible and universally applicable to application scenarios such as multi-user and multi-device digital signatures. Thus, although there is a certain amount of computing time and data transmission time when calculating the intermediate values before the signature of this scheme, this scheme is still highly feasible and has wide application prospects. Anti-forgery attacks. Multi-party co-signing is inherently resistant to forgery attacks, During the signature process, the complete private key does not appear in the memory of any party, eliminating the risk of forgery of digital signatures due to private key leakage, and the complete signature cannot be generated without the participation of any party after the public key of the co-signing group is determined. In addition, the identity of each user is legitimate at the time of signature group public key generation, even if the forger forges the signature by impersonating a node in the signature process, the forged signature cannot pass the verification in the final signature verification process with the participation of the group public key, so the forger fails to forge the signature. Taking 3-party collaboration as an example, assume that the authenticated collaborative participants are userA{dA, PA}, userB{dB, PB}, userC{dC, PC}, and the generated legitimate group public key is . The counterfeiter forgerA attacks the participant userA, and forges information such as the same identity IDA, the same public key PA (the private key is different dX) and other information. The steps for forging the signature are as follows: (1) Forger forgerA requests participant chain to calculate the second part of the signature intermediate value (Sign_D) ① ForgerA initiates a signature, first selects the private value D0 = b, calculates D1 = dx*D0, and then sends D1 to the participant userB; ② The participant userB uses the private key dB to calculate D2 = dB*D1, and then sends D2 to the participant userC; ③ The participant userC uses the private key dC to calculate D3 = dC*D2, where D = D3 = dC*dB*dX*b, and finally returns D to the signature initiator forgerA. (2) The forger forgerA calculates the first part of the signature r (Sign_r) ① ForgerA calculates ZA = Hv(ENTL∥IDA∥a∥b∥P∥pk), and calculates M’ = ZA∥M; ② The counterfeiter forgerA calculates e = Hv(M′), and converts the text e to an integer, where Hv() is a one-way function; ③ The forger forgerA calculates the value K = (KX + KA + KB)modn based on the data Ki sent by each participant, where KX = kX/dX, and then calculates the public point Q = K[*]G = (x1, y1), and convert the data type of x1 to integer. ④ Calculate the signature r = (e+x1) mod n, and return ③ if r = 0 or r+k = n. (3) Forger forgerA calculates the second part of signature s (Sign_s) ⑤ ForgerA uses the signature intermediate value D, private value b, self-calculated K value and the first part of the signature r value to calculate the second part of the signature s value, where s = (K + r)*D/b − r = (K + r)*dC dB dX − r. (4) Verification of the forged signature result (r′, s′) Verify the forged digital signature by deriving the verification formula , where , t = (r′ + s′)modn. The detailed verification steps of the signature are described in Section 4.4. (11) It can be seen from the verification result of the forged signature that Q’ ≠ Q, , then R ≠ r’, that is, the verification fails and the forged signature fails. Feasibility and flexibility validation. In order to verify the feasibility and flexibility of this solution, we choose a specific application scenario: an enterprise produces an important product for a large number of users, and needs qualified manufacturers of semi-finished products, and qualified semi-finished products need qualified manufacturers of components, qualified parts manufacturers need qualified raw material suppliers to provide, which forms a supply chain. In order to ensure that the quality of the final product is recognized and accepted by the user, the company needs the company in the supply chain to collaborate to sign a product quality commitment to users, and the user can verify the signature to trust the quality of the product. Because once the user’s verification is passed, it means that the supply chain of the product is trustworthy. In response to this scenario, we separately set the private key and random number of the SM2 digital signature, and the private keys and random numbers of multiple companies in the industry chain. In order to facilitate the experiment, we take the same values for the private keys and random numbers of multiple enterprises in the industry chain as the original SM2 digital signature scheme: dA = “0x128B2FA8 BD433C6C 068C8D80 3DFF7979 2A519A55 171B1B65 0C23661D 15897263”; k = “0x6CB28D99 385C175C 94F94E93 4817663F C176D925 DD72B727 260DBAAE 1FB2F96F”. (1) The plaintext message digest of the original SM2 digital signature scheme uses the SM3 algorithm to calculate the hash e(Hash) and the public key P(X, Y), and the digital signature (r, s) and signature verification results are shown in Fig 6. Download: PPT PowerPoint slide PNG larger image TIFF original image Fig 6. Original SM2 digital signature and verification data. https://doi.org/10.1371/journal.pone.0268245.g006 (2) The SM3 algorithm is used to calculate the hash e(Hash) and group public key P(X, Y), as well as the digital signature (r, s) and signature verification results for the plaintext “message digest” of the SM2 industry chain multi-enterprise collaborative digital signature scheme. The results of co-signatures are shown in Figs 7–9 for 3, 8, and 23 parties. Download: PPT PowerPoint slide PNG larger image TIFF original image Fig 7. 3-party co-digital signature and verification data. https://doi.org/10.1371/journal.pone.0268245.g007 Download: PPT PowerPoint slide PNG larger image TIFF original image Fig 8. 8-party co-digital signature and verification data. https://doi.org/10.1371/journal.pone.0268245.g008 Download: PPT PowerPoint slide PNG larger image TIFF original image Fig 9. 23-party co-digital signature and verification data. https://doi.org/10.1371/journal.pone.0268245.g009 From the above experimental results, it can be seen that this scheme has strong flexibility, and the participants of the supply chain can be any n parties such as 3 parties or 8 parties to participate in the collaborative signature, which can meet the requirements of any multi-party hierarchical evaluation of the same document in electronic transactions, making the multi-party collaborative signature scheme have stronger applicability. In addition, this scheme can obtain legal signature results for different number of supply chain participants and the verification result is correct, which shows the correctness and feasibility of this scheme. In addition, for the n-party co-signing scheme, unless the hacker obtains the signature key of the n − 1 signer, the legitimate signature cannot be forged, so the multi-party co-signing scheme in this paper also has sufficient security. Performance analysis. For the differences caused by running in different time periods in the native environment, firstly, the original SM2 scheme will be carried out several times with multiple co-signers at the same time, and then the running time of multiple signatures of the original SM2 scheme (the difference in the values taken should not be too large) will be taken, and finally the average value will be used as the standard value for floating values, and the running time of multiple co-signers in the corresponding range of floating values will be selected. For different parties, 100 tests were conducted, and the number of multiparty co-signers was taken as 3, 8, 23, etc., and then the average value of the running time was calculated. The average running time of the digital signature interface and signature verification interface of the original SM2 scheme and the multi-party collaboration algorithm are shown in Fig 10. Download: PPT PowerPoint slide PNG larger image TIFF original image Fig 10. Average runtime of SM2 scheme and multi-party co-digital signature and signature verification. https://doi.org/10.1371/journal.pone.0268245.g010 The above data counts the average running time of the digital signature interface of the original SM2 scheme and the multi-party collaboration algorithm (that is, Algorithm 1 and Algorithm 2), and after running Algorithm 1 and Algorithm 2 several times simultaneously, changing only the number of supply chain participants in the collaborative signature each time, and finally taking the running time of the original SM2 signature as the standard value to take the running time of multiple interfaces and calculate the average value. From the above statistical results, it can be seen that there is no additional burden on the performance of the signature scheme when increasing the number of multi-signers, because the signature time of Algorithm 2 here is only the interface time for the final calculation of the signature result by the tested signature initiator, and the number of supply chain participants does not correlate with the signature time, so the signature times of Algorithm 1 and Algorithm 2 are almost the same. In addition, for the results of multi-party co-signing, signature verification has been performed using the standard SM2 verification interface, and the verification in Section 7.2.1 experimental results passed proving that multi-party co-signing is feasible, flexible and universally applicable to application scenarios such as multi-user and multi-device digital signatures. Thus, although there is a certain amount of computing time and data transmission time when calculating the intermediate values before the signature of this scheme, this scheme is still highly feasible and has wide application prospects. Conclusion In order to prevent the leakage of the user’s key stored in the client in the mobile Internet environment and to meet the needs of multiple entities operating on the same file, this paper designs a multi-party collaborative signature scheme based on SM2 based on the idea of collaborative signature. It allows users to hold their own private key values and jointly complete the SM2 digital signature without revealing the key, and both the group public key and signature must be jointly generated by multiple parties, and the complete signature key cannot be recovered in the process, fully guaranteeing the security of the signature key. In addition, we attribute the security of co-signatures to standard SM2 signatures, thus proving the security of our proposed protocol, that is, if the original SM2 is probabilistic polynomial-time unforgeable, then our protocol also satisfies probabilistic polynomial-time unforgeability. Finally, this article has completed the test and evaluation for the correctness and performance of the scheme. The experimental results show that the multiparty co-signing takes slightly more time than the original SM2 signature once for the same device in an approximately consistent environment, but the signature verification interface and verification time are consistent. The co-signature does not change the format of the signature result and the signature verification algorithm. It has high compatibility with the standard SM2 digital signature algorithm, so it has a wide application prospect in practical applications, especially in the multi-user and multi-device application scenario with strong scalability and practicality.
TI - Multi-party co-signature scheme based on SM2
JF - PLoS ONE
DO - 10.1371/journal.pone.0268245
DA - 2023-02-06
UR - https://www.deepdyve.com/lp/public-library-of-science-plos-journal/multi-party-co-signature-scheme-based-on-sm2-Smv66oLI0r
SP - e0268245
VL - 18
IS - 2
DP - DeepDyve
ER -