Identity-Based Threshold Group Signature Scheme of Blockchain Verification

Abstract

In the e-commerce scenario, the signature schemes generally have to meet four requirements: public verification, integrity, traceable and efficiency. To achieve the above goals, the paper proposes a identity-based threshold group signature scheme which can not only simplify the process of key management, but also allow to trace the user identities. To protect the user privacy, the scheme blinds the user identities and stores them on the blockchain to prevent the malicious members from tampering with the content. Security analysis shows that the proposed signature, whose difficulty is equivalent to solve the discrete logarithm problem, achieves a high level of anonymity and can resist impersonation attacks. Computational complexity analysis shows that the new method with low computation overhead and high communication efficiency can be effectively adapted to the electronic commerce scene.

1 Introduction

Electronic commerce is a business activity, which focuses on commodity exchange technology. However the security situation of e-commerce has been getting worse. Billions of accounts have been stolen or controlled by the hackers, and millions of the user identities are leaked, even publicly traded. Therefore, it is necessary to study the signature schemes applicable to the e-commerce scenarios, which can protect the user privacy and information behaviors, prevent message forgery and repudiation, and guarantee integrity of the trading contents.

The identity-based signature scheme can verify the message content to ensure that the message is not tampered with during transmission. In the e-commerce scenario, the available signature schemes generally have to meet four requirements: public verification, integrity, traceable and efficiency. Previously, the user identities were the pseudonym information used by the user to participate in the signing process and the temporary identify labels were usually generated through the public key encryption algorithm with anonymity. For the identity-based signature scheme, the user can select his ID number, E-mail, mobile phone number as his identity for tracing after the event, which simplifies the key management process.

Blockchain is a distributed database technology which can record the transactions. The characteristics of blockchain are decentralization, anonymization and non-tampering. It handles distrust among nodes and has been widely applied in the fields of e-money, financial investment and IoT. As described above, the signatures and the blinded user identities can be stored in the blockchain, which guarantees the public verification of the signatures, and prevents the third party from maliciously tampering with the public information.

2 Related Work

In 1994, Marsh firstly proposed the concept of trusted computing and elaborated on the canonical representation of trust metrics. Based on the typical mathematical problems, existing threshold group signature schemes can be divided into three categories: 1. Based on prime factorization of large numbers. 2. Based on the discrete logarithm problem. 3. Based on the elliptic curve discrete logarithm problem. According to the way of key distribution, the threshold group signature schemes are mainly divided into two categories: 1. The ones with the trusted center. 2. The ones without the trusted center.

In 2004, Chen [1] proposed a signature scheme based on the elliptic curve encryption algorithm, and the length of the private key was short. However, it lacked the revoking operation and could not trace the user identities. In 2018, Wang [2] proposed a threshold group signature scheme which was introduced through collaboration between the blockchain and the trusted center. Dong [3] proposed an ECC threshold signature scheme with the elliptic curve discrete logarithm difficulty, which could trace the user identities with the help of the trusted center and effectively resist the malicious participants forging the final signature. The above threshold group signature schemes are based on the Shamir secret sharing method. Some other secret sharing methods will be discussed in the following part.

Yage [4] proposed a threshold signature scheme with strong forward security based on the Chinese Remainder theorem. The scheme updated the private key regularly to improve the security level and excluded the trusted center to increase the availability. Wang [5] proposed a scheme based on Asmuth-Bloom scheme applying on the blockchain voting scene. The method without the participation of the trust center was able to synthesize the final signature with the signature shares, during which the group private key was not exposed and the sensitive data would be validated to protect the user privacy during data transmitting in the blockchain unsafe transmission channel.

The paper [6] proposed an identity-based threshold group signature scheme based on the bilinear mapping. The master key of the scheme was distributed into the whole group and the user’s signature key was stored in a threshold way. In [7], the threshold group signature scheme with the elliptic curve discrete logarithm difficulty was proposed. The method allowed signature verification and thresholds modification. The paper [8] proposed a threshold group signature scheme based on Elliptic Curve Cryptosystem with characteristics of easy verification, unforgeability and undeniability. The scheme had a shorter key length, lower computation and bandwidth requirement. [9] and [10] proposed two ECDSA threshold signature schemes. Both schemes allowed participants to reconstruct keys. Gennaro et al. [11] proposed a threshold signature scheme which realized the multi-party control on the Bitcoin scene.

The concept of secret sharing was first proposed by Shamir [12] and Blackey [13]. The idea is to split the target secret $S$ into $N$ copies and each share will be sent to its corresponding participant. When need to reconstruct the secret, we should involve a certain number of participants, the number of whom should be greater than or equal to a specified threshold $t$. In the e-commerce scenario, the signature schemes generally have to meet four requirements: public verification, integrity, traceable and efficiency. To achieve the above goals, the paper proposes an identity-based threshold group signature scheme, which can not only simplify the process of key management, but also allow us to trace the user identities. To protect the user privacy, the scheme blinds the user identities and stores them on the blockchain to prevent the malicious members from tampering with the content.

3 Proposed Scheme

3.1 Architecture

The participants in the proposed scheme include user (U), trust center (TC), signature compositor (SC) and signature verifier (V). The proposed threshold group signature scheme includes seven parts: setup, registration, signature shares generation, combining signature shares, signature verification, signature opening and revocation.

The following section describes the details of the proposed threshold group signature scheme. For convenience, the symbols are defined as Table 1.

Table 1. Symbols defined for the proposed scheme

• 1. System initialization

  TC initializes the system parameters, and then mainly accomplishes two tasks: the first is to set the parameters for the proposed threshold group signature scheme and build the system template parameters; the second is to generate the key information and hash function for TC. The process is as follows:

• 1.1 Determine the participant number $N$ and its corresponding threshold $t$ for the proposed method, where $t \le N$. $F_{p}$ denotes the finite field, wherein $p$ is a large prime number and the generator is $g$.

• 1.2 TC generates its private key and other related information depending on the template parameters generated in the previous step. First, TC selects its private key $T_{s} = s$, $s \in {\mathbf{\rm Z}}_{p}^{*}$, and its corresponding public key is $T_{p} = g^{s} \bmod p$. Then TC selects a $(t - 1)$ degree polynomial $f(x) = \sum\limits_{i = 1}^{t - 1} {a_{i} x^{i} } + a_{0} \bmod p$, $a_{j} \in [1,p - 1]$, $j = 0,1, \ldots ,t - 1$, where $a_{0} \in {\mathbf{\rm Z}}_{p}^{*}$ is the secret to be shared. The variable $a_{0} = g_{s} = f(0)$ represents the group private key, and its group public key is $g_{p} = g^{{g_{s} }} \bmod p$.

• 1.3 Select a one-way hash function $h:\{ 0,1\}^{*} \to F_{p}$.

• 1.4 $\left( {s,g_{s} ,f\left( x \right)} \right)$ is the private information of TC, and $(T_{p} ,g_{p} ,h,g,p)$ is the public information.

• 2. User Registration

  When the user $U_{i}$ wants to join the group, the registration process is performed. First, $U_{i}$ sends its identity to TC, and TC will verify it. After the verification is passed, the identity will be blinded and sent to $U_{i}$. The blinded identity is verified and blinded for the second time. The secondary blinded identity along with the partial key which is generated by $U_{i}$ is sent to TC. After TC receives the above information, it performs the verification operation, and stores the result on the blockchain. After that, TC generates another part of the private key for the user and sends it to $U_{i}$. After $U_{i}$ verifies the information, the user synthesizes the key generated by himself and the partial key generated by TC to generate his own private key and the public key. The details are as follows:

• 2.1. The user $U_{i}$ sends his identity $ID_{i}$ to TC.

• 2.2. After TC receives $ID_{i}$, it checks whether the user has already registered or not. If the user does, TC rejects his request. Otherwise, TC generates $u \in {\mathbf{\rm Z}}_{p}^{*}$ randomly and calculates: $U = g^{u} \bmod p$, $ID_{i1} = s \times h(ID_{i} ) + u$. After that, TC sends $\left( {U,ID_{i1} } \right)$ to the user $U_{i}$.

• 2.3. After the user $U_{i}$ receives $\left( {U,ID_{i1} } \right)$, the data pair will be verified with $g^{{ID_{i1} }} \bmod p = \left( {T_{p}^{{h(ID_{i} )}} \times U} \right)\bmod p$. If the verification fails, it means that the data is tampered with during the transmission process, and the user $U_{i}$ requests TC to resend the data. If the verification succeeds, the user $U_{i}$ selects his partial private key $x_{i} \in {\mathbf{\rm Z}}_{p}^{*}$ and calculates $X_{i} = g^{{x_{i} }} \bmod p$. The user $U_{i}$ needs to perform the secondary blindness operation on his identity to increase the security of the solution. First, the user $U_{i}$ randomly selects $v_{i} \in {\mathbf{\rm Z}}_{p}^{*}$ and calculates $V_{i} = g^{{v_{i} }} \bmod p$. Then he performs the secondary blinding operation on his identity with $ID_{i2} = x_{i} \times h\left( {ID_{i1} } \right) + v_{i}$. After that, $U_{i}$ sends $\left( {X_{i} ,V_{i} ,ID_{i1} ,ID_{i2} } \right)$ to TC.

• 2.4. After TC receives $\left( {X_{i} ,V_{i} ,ID_{i1} ,ID_{i2} } \right)$, it first checks the data pair with $g^{{ID_{i2} }} \bmod p = (X_{i}^{{h(ID_{i1} )}} \times V_{i} )\bmod p$. If the verification succeeds, it denotes that the user has successfully generated his blinded identity, and TC will store $\left( {X_{i} ,ID_{i} ,ID_{i2} } \right)$ in the user information list UL, which will be used to trace the user identity afterwards. Then TC assigns another private key $y_{i}$ to the user where $y_{i} = f(ID_{i2} ) = \sum\limits_{j = 1}^{t - 1} {a_{j} (ID_{i2} )^{j} } + a_{0} \bmod p$. In order to prevent the malicious third party from intercepting $y_{i}$, $y_{i}$ needs to be encrypted to $E_{{PK_{{U_{i} }} }} (y_{i} )$ with the public key of $U_{i}$.

• 5. 2.5 After the user receives $E_{{PK_{{U_{i} }} }} (y_{i} )$, the user decrypts it with his private key to obtain the plaintext $y_{i}$. The user $U_{i}$ can then generate his own private key with $d_{i} = x_{i} + y_{i}$. The corresponding public key for $U_{i}$ is $D_{i} = g^{{d_{i} }} \bmod p$. At this point, the user registration process ends.

• 3. Generating Signature Shares

  For the proposed threshold group signature scheme, the set of participants is denoted as $U' = \{ U_{1} ,U_{2} , \ldots ,U_{N} \}$, and the final legal signature can be generated with at least $t$ $\left( {t \le N} \right)$ signature shares. For convenience, we will only consider $t$ signature shares to combine the final signature, and the user set is denoted as $U = \{ U_{1} ,U_{2} , \ldots ,U_{t} \}$. After registration, the user in the set firstly generates his signature share corresponding to the message, and then delivers it to ${\text{SC}}$ for synthesizing. In the end, ${\text{V}}$ checks the final signature and stores it in the blockchain. For the user $U_{i}$, when to generate his signature share, he first generates a random number $k_{i} \in {\mathbf{\rm Z}}_{p}^{*}$, and then obtains $r_{i} = g^{{k_{i} }} \bmod p$. We can obtain the corresponding hash value $z = h(m)$ from the message $m$, and then calculates the signature share with $s_{i} = k_{i} - zd_{i} I_{i}$, where $I_{i} = \prod\limits_{j = 1,i \ne j}^{t} {\frac{{ID_{j2} }}{{ID_{j2} - ID_{i2} }}\bmod p}$, $1 \le i \le t$. Since $I_{i}$ is public, it can be pre-computed and published to reduce the computational complexity. Finally, the user $U_{i}$ sends the signature share $\left( {r_{i} ,s_{i} } \right)$, the message $m$ and its corresponding identity $ID_{i2}$ to SC.

• 4. Combine signature shares

  After SC receives greater than or equal to $t$ signature shares, the final signature can be synthesized. Before that, we need to verify the received signature shares. In order to trace the user identify afterwards and prevent the third party from tampering with the content, the final signature needs to be stored into the blockchain. When SC verifies $\left( {r_{i} ,s_{i} } \right)$ and $ID_{i2}$, he first calculates the corresponding hash value $z = h(m)$ from the message $m$, and then performs the verification with $g^{{s_{i} }} D_{i}^{{zI_{i} }} = r_{i} \bmod p$. If the above equation holds, we can perform the subsequent signature synthesis operation, otherwise the signature compositor will reject the signature share. When performing signature synthesis, we first calculate $R = \prod\limits_{i = 1}^{t} {r_{i} }$, $S = \sum\limits_{i = 1}^{t} {s_{i} }$, and $\left( {R,S} \right)$ is the final synthesized signature. In order to verify the synthesized signature, we should calculate $W = \prod\limits_{i = 1}^{t} {X_{i}^{{I_{i} }} } \bmod p$. SC sends $\left( {R,S,W} \right)$ and the message $m$ to V for verification.

• 5. Signature verification

  After V receives the above information, it needs to verify the signature. First, V performs a hash function $z = h(m)$ on the received message $m$, and then verifies the final signature with $R = g^{S} \times (g_{p} W)^{z}$. When the verification holds, ${\text{V}}$ stores $\left( {ID_{i2} ,r_{i} ,s_{i} } \right)$ and the synthesized signature $\left( {R,S,W} \right)$ in the blockchain for traceability.

• 6. Signature Opening

  When dispute occurs, we need to access the blockchain and TC to trace the target identities from the given signature. During the process, the participation of SC and V is not required, and the feature of the blockchain guarantees the data against tampering, which not only increases the security level of the system, but also reduces the number of interactions to increase the efficiency. For the synthesized signature $\left( {R,S} \right)$, we need to access the blockchain when to trace its corresponding identity. When accessing the blockchain, we need to search for $(ID_{i2} ,r_{i} ,s_{i} )$ corresponding to $(R,S)$. Among them, $ID_{i2}$ is the secondary blinding identity, and the third party cannot infer the user identity. Then we need to access TC and obtain $(X_{i} ,ID_{i} ,ID_{i2} )$ through $ID_{i2}$, among which $ID_{i}$ is the user identity.

• 7. Members Revoking

  When a member withdraws from the group, only TC needs to perform most of the calculation tasks. The revocation message along with attached information needs to be broadcast to other users. Other users only need to perform a small number of operations to revoke the target member. First, TC needs to reselect a $t - 1$ order polynomial, then recalculate the new partial key $y_{i} = f(ID_{i2} )$ for each member $ID_{i2}$, and send the revocation message together with the encrypted message $PK_{{U_{i} }} (y_{i} )$ to other users. Other users only need to update their private keys with $d_{i} = x_{i} + y_{i}$, and their corresponding public keys with $D_{i} = g^{{d_{i} }} \bmod p$. After that, TC can delete the specified member $ID_{i2}$ from the group.

4 Security Analysis

4.1 Correctness Analysis

Theorem 1.

Two verification equations $g^{{ID_{i1} }} \bmod p = (T_{p}^{{h(ID_{i} )}} \times U)\bmod p$ and $g^{{ID_{i2} }} \bmod p = (X_{i}^{{h(ID_{i1} )}} \times V_{i} )\bmod p$ are established when any user registers.

Proof:

When the user $U_{i}$ begins to register, the user $U_{i}$ and TC are required to perform the two-way authentication. The corresponding verification formula is $g^{{ID_{i1} }} \bmod p = (T_{p}^{{h(ID_{i} )}} \times U)\bmod p$, $g^{{ID_{i2} }} \bmod p = (X_{i}^{{h(ID_{i1} )}} \times V_{i} )\bmod p$. Because of $ID_{i1} = s \times h(ID_{i} ) + u$, we can obtain $g^{{ID_{i1} }} \bmod p = g^{{(s \times h(ID_{i} ) + u)}} \bmod p$$= (g^{s} )^{{h(ID_{i} )}} g^{u} \bmod p$. From $U = g^{u} \bmod p$ and $T_{p} = g^{s} \bmod p$, we can get $g^{{ID_{i1} }} \bmod p = (g^{s} )^{{h(ID_{i} )}} g^{u} \bmod p = (T_{p}^{{h(ID_{i} )}} \times U)\bmod p$. Because of $ID_{i2} = x_{i} \times h(ID_{i1} ) + v_{i}$, we can obtain $g^{{ID_{i2} }} \bmod p = g^{{(x_{i} \times h(ID_{i1} ) + v_{i} )}} \bmod p$$= (g^{{x_{i} }} )^{{h(ID_{i1} )}} g^{{v_{i} }} \bmod p$. From $X_{i} = g^{{x_{i} }} \bmod p$ and $V_{i} = g^{{v_{i} }} \bmod p$, we can calculate $g^{{ID_{i2} }} \bmod p = (g^{{x_{i} }} )^{{h(ID_{i1} )}} g^{{v_{i} }} \bmod p = (X_{i}^{{h(ID_{i1} )}} \times V_{i} )\bmod p$.

Theorem 2.

When to generate the synthesized signature, the verification equation $r_{i} = g^{{s_{i} }} D_{i}^{{zI_{i} }} \bmod p$ of SC holds.

Proof:

The user $U_{i}$ begins to sign the message $m$ and generate the signature share which will be sent to SC for signature synthesis. After receiving the information, SC should verify the message to ensure that the message is not maliciously tampered by a third party with $r_{i} = g^{{s_{i} }} D_{i}^{{zI_{i} }} \bmod p$. Because of $s_{i} = k_{i} - zd_{i} I_{i}$, we can obtain $g^{{s_{i} }} = g^{{k_{i} - zd_{i} I_{i} }} = g^{{k_{i} }} (g^{{d_{i} }} )^{{ - zI_{i} }} \bmod p$. From $r_{i} = g^{{k_{i} }} \bmod p$ and $D_{i} = g^{{d_{i} }} \bmod p$, we can get $g^{{s_{i} }} = r_{i} (D_{i} )^{{ - zI_{i} }} \bmod p$, and then we can obtain $g^{{s_{i} }} D_{i}^{{zI_{i} }} = r_{i} \bmod p$.

Theorem 3.

After generating the final signature, the verification equation $R = g^{S} \times (g_{p} W)^{z}$ of the signature verifier holds.

Proof:

After the signature compositor synthesizes the signature shares, the final signature is sent to the signature verifier for verification with $R = g^{S} \times (g_{p} W)^{z}$. Because of $s_{i} = k_{i} - zd_{i} I_{i}$, $S = \sum\limits_{i = 1}^{t} {s_{i} }$, we can obtain $g^{S} = g^{{\sum\limits_{i = 1}^{t} {s_{i} } }} = g^{{\sum\limits_{i = 1}^{t} {(k_{i} - zd_{i} I_{i} )} }} = g^{{\sum\limits_{i = 1}^{t} {k_{i} } }} g^{{ - \sum\limits_{i = 1}^{t} {(zd_{i} I_{i} )} }}$$= \prod\limits_{i = 1}^{t} {g^{{k_{i} }} } \prod\limits_{i = 1}^{t} {g^{{ - zd_{i} I_{i} }} }$. From $d_{i} = x_{i} + y_{i}$, $r_{i} = g^{{k_{i} }} \bmod p$ and $R = \prod\limits_{i = 1}^{t} {r_{i} }$, we can get $g^{S} = \prod\limits_{i = 1}^{t} {g^{{k_{i} }} } \prod\limits_{i = 1}^{t} {g^{{ - zd_{i} I_{i} }} } = \prod\limits_{i = 1}^{t} {r_{i} } \prod\limits_{i = 1}^{t} {g^{{ - z(x_{i} + y_{i} )I_{i} }} } = R\prod\limits_{i = 1}^{t} {g^{{ - z(x_{i} + y_{i} )I_{i} }} }$. Then we can calculate $g^{S} \prod\limits_{i = 1}^{t} {g^{{z(x_{i} + y_{i} )I_{i} }} } = R = g^{S} \prod\limits_{i = 1}^{t} {(g^{{zx_{i} I_{i} }} } g^{{zy_{i} I_{i} }} )$$= g^{S} g^{{z\sum\limits_{i = 1}^{t} {f(ID_{i2} )I_{i} } }} \prod\limits_{i = 1}^{t} {g^{{zx_{i} I_{i} }} }$. According to Lagrange interpolation formula, we can obtain $z\sum\limits_{i = 1}^{t} {f(ID_{i2} )I_{i} } = za_{0} = zg_{s}$. Then we can get $R = g^{S} g^{{zg_{s} }} \prod\limits_{i = 1}^{t} {g^{{zx_{i} I_{i} }} }$. Because of $g_{p} = g^{{g_{s} }} \bmod p$ and $X_{i} = g^{{x_{i} }} \bmod p$, we can obtain $R = g^{S} g^{{zg_{s} }} \prod\limits_{i = 1}^{t} {g^{{zx_{i} I_{i} }} } = g^{S} g_{p}^{z} \prod\limits_{i = 1}^{t} {g^{{zx_{i} I_{i} }} } = g^{S} (g_{p} \prod\limits_{i = 1}^{t} {X_{i}^{{I_{i} }} } )^{z}$. Because of $W = \prod\limits_{i = 1}^{t} {X_{i}^{{I_{i} }} } \bmod p$, we can obtain $R = g^{S} \times (g_{p} W)^{z}$.

4.2 Threshold Safety Analysis

The threshold feature of the proposed scheme means that for a $(t,n)$ threshold signature scheme, the secret will be dispersed into a group comprising of $n$ members, and the subset of no less than $t$ members can use their respective possessions to produce the final signature. On the other hand any subset of less than $t$ members cannot recover the secret or obtain the correct result.

The process to obtain the threshold group signature includes generation of signature shares and synthesis of signature shares. For $n$ participants, when to generate the signature shares, each user utilizes its own private key $k_{i} \in {\mathbf{\rm Z}}_{p}^{*}$ to sign the message and generates the signature share with the formula $s_{i} = k_{i} - zd_{i} I_{i}$. After the trusted center receives the signature shares $\left\{ {\left( {r_{i} ,s_{i} } \right)\left| {t \le i} \right. \le n} \right\}$ from participants, the trusted centers will perform the synthesis operations with $R = \prod\limits_{i = 1}^{t} {r_{i} }$ and $S = \sum\limits_{i = 1}^{t} {s_{i} }$. $\left( {R,S} \right)$ is the final synthesized signature which needs to be verified with the formula $R = g^{S} \times (g_{p} W)^{z}$.

At least $t$ nodes are required to synthesize the signature shares. When to combine less than $t$ signature shares, the synthesis will fail. When obtain the final signature, the content must be verified with $R = g^{S} \times (g_{p} W)^{z}$. According to Lagrange interpolation formula, we can obtain $z\sum\limits_{i = 1}^{t} {f(ID_{i2} )I_{i} } = za_{0} = zg_{s}$. If a malicious third party wants to obtain the private group key $g_{s}$, he needs at least $t$ participants cooperating to succeed.

If the attacker has obtained the public key $g_{p}$ and $g$, he wants to calculate the private group key $g_{s}$ through $g_{p} = g^{{g_{s} }} \bmod p$, and the difficulty of the operation is reduced to the discrete logarithm problem which is computationally infeasible. In the end, the above analysis shows that the proposed scheme is safe.

4.3 Anonymity Analysis

The anonymity of the proposed threshold signature scheme means that for a given group signature, no one else can know the true identities of the participants except for TC or themselves.

When a user $U_{i}$ wants to join the group, he first sends his identity $ID_{i}$ to TC. TC will check its repeatability, and then blinds the user identity with $ID_{i1} = s \times h(ID_{i} ) + u$, which takes $u \in {\mathbf{\rm Z}}_{p}^{*}$ and his private key $s$ as input. $ID_{i1}$ will be sent to the user who will check its integrity. After that, the user $U_{i}$ will use his partial private key $x_{i} \in {\mathbf{\rm Z}}_{p}^{*}$ and a random value $v_{i} \in {\mathbf{\rm Z}}_{p}^{*}$ to perform the secondary blinding operation on his identity with $ID_{i2} = x_{i} \times h\left( {ID_{i1} } \right) + v_{i}$.

The two items $ID_{i1}$ and $ID_{i2}$ which are respectively generated by the user and TC are public, while the user id $ID_{i}$ is secret. Other unauthorized nodes are not able to obtain the user true identity without the knowledge of the values of $s$, $u$, $x_{i}$ and $v_{i}$. Even the attacker obtains those values, it is still difficult for him to retrieve the identities through the one-way hash function $h (x )$. The two items $ID_{i1}$ and $ID_{i2}$ are stored into the blockchain which cannot be tampered with. Based on the above analysis, the user identity can achieve a high level of anonymity which could prevent the malicious third party from tampering with the user sensitive information.

4.4 Unforgeability Analysis

Unforgeability means that any participant cannot impersonate another one to generate the legal signature. In real life, TC and the user may impersonate each other to sign the given message with another identity. The attack scenes can be divided into two cases: Case 1: TC masquerades as member $U_{i}$, and signs the message $m$ with the identity of $U_{i}$. Case 2: The user $U_{j}$ masquerades as member $U_{i}$, and signs the message $m$ with the identity of $U_{i}$.

For the first case, TC spoofs the identity of $U_{i}$. The blinded identity set $\{ ID_{i1} ,ID_{i2} ,,ID_{it} \}$ is public, and TC can know the $(t - 1)$ degree polynomial $f(x) = \sum\limits_{i = 1}^{t - 1} {a_{i} x^{i} } + a_{0} \bmod p$. The trusted center randomly selects $u^{\prime}_{i} \in Z_{p}^{*}$ to generate $\left( {U',ID_{i1} '} \right)$ and selects $x_{{_{i} }}^{'} \in {\mathbf{\rm Z}}_{p}^{*}$ as the user $U_{i}$ partial private key to calculate $X_{{_{i} }}^{'} = g^{{x_{{_{i} }}^{'} }} \bmod p$. TC performs secondary blindness on the identity of the user $U_{i}$ by randomly selecting $v_{{_{i} }}^{'} \in {\mathbf{\rm Z}}_{p}^{*}$ to calculate $V_{{_{i} }}^{'} = g^{{v_{{_{i} }}^{'} }} \bmod p$. Then he performs the secondary blinding operation with $ID_{{_{i2} }}^{'} = x_{{_{i} }}^{'} \times h\left( {ID_{{_{i1} }}^{'} } \right) + v_{{_{i} }}^{'}$. After that, TC stores $\left( {X_{{_{i} }}^{'} ,ID_{{_{i} }}^{'} ,ID_{{_{i2} }}^{'} } \right)$ in the information list, and then generates the final signature. In the end, TC stores $\left( {ID_{{_{i2} }}^{'} ,r_{{_{i} }}^{'} ,s_{{_{i} }}^{'} } \right)$ and the synthesized signature $\left( {R',S'} \right)$ in the blockchain. However, the user $U_{i}$ can obtain the data pair $\left( {ID_{{_{i2} }}^{'} ,r_{{_{i} }}^{'} ,s_{{_{i} }}^{'} ,R',S'} \right)$ from blockchain and $\left( {X_{{_{i} }}^{'} ,ID_{{_{i} }}^{'} ,ID_{{_{i2} }}^{'} } \right)$ from TC with his own $X_{i}$. If TC wants to pass the verification, he must generate the value $X_{{_{i} }}^{'}$ guaranteeing $X_{{_{i} }}^{'} = X_{i}$, which means that TC has to obtain $x_{i} \in {\mathbf{\rm Z}}_{p}^{*}$ from $X_{i} = X_{{_{i} }}^{'} = g^{{x_{i} }} \bmod p$. The question is reduced to discrete logarithm problem, and the operation is computationally infeasible.

For the second scenario, the user $U_{j}$ poses as the node $U_{i}$ to sign the message $m$. At this time, the user $U_{j}$ only knows $ID_{i2}$ of the user $U_{i}$. The user $U_{j}$ randomly selects $u^{\prime}_{i} \in Z_{p}^{*}$, and selects $x_{{_{i} }}^{'} \in {\mathbf{\rm Z}}_{p}^{*}$ as the user $U_{i}$ partial private key to calculate $X_{{_{i} }}^{'} = g^{{x_{{_{i} }}^{'} }} \bmod p$. Then the user $U_{j}$ will perform the secondary identity blind operation to generate $\left( {X_{{_{i} }}^{'} ,ID_{{_{i} }}^{'} ,ID_{{_{i2} }}^{'} } \right)$. In the end, TC will combine the signature shares to generate the final signature $\left( {R',S'} \right)$, which will be sent to SC for verification with $R' = g^{S'} \times (g_{p} W)^{z}$. If the user $U_{j}$ wants to pass the verification, he must guarantee the following equation holds $z\sum\limits_{i = 1}^{t} {f(ID_{i2} )I_{i} } = za_{0} = zg_{s} = z\sum\limits_{i = 1}^{t} {f'(ID_{i2} )I_{i} }$. $I_{i}$ is public, and the user $U_{j}$ can obtain $z = h(m)$ from the message $m$, so the user $U_{j}$ should obtain the function $f'(ID_{i2} )$ which meets $f(ID_{i2} ) = f'(ID_{i2} )$. Because of $f(x) = \sum\limits_{i = 1}^{t - 1} {a_{i} x^{i} } + a_{0} \bmod p$, the user $U_{j}$ needs to guess the values of $a_{i}$, $0 \le i \le t - 1$, which probability is ${\rm P}r = \frac{1}{{(p - 1)^{t} }}$. Because $p$ is a large prime number, the adversary can only succeed with a negligible probability.

5 Performance Analysis

5.1 Functionality Comparison

In this part, we give the functionality comparison of the proposed scheme with other related ones as shown in the following Table 2. We mainly focus on the five properties: public verifiability, sensitive information hiding, members revocable, traceability and anti-collusion.

Table 2. Functionality comparison

Public verifiability means that the final signature can be verified by the others apart from SV. Sensitive information hiding denotes that anyone else can not fetch the user identity from the public information advertised in the method. This property allows participants to opt out of the group, which is especially important in mobile Internet scenarios. Traceability represents that the supervisor can perform post hoc analysis to trace the identity information of the signer from the synthesized signature, mainly used in the auditing scenario. Anti-collusion means that any participant cannot impersonate another one to generate the legal signature. Note that the proposed scheme supports all the five properties compared with other related algorithms.

5.2 Performance Comparison

We define several notations to denote the operations in the proposed scheme as Table 3.

Table 3. Defined symbols for computational complexity

We mainly consider the three steps in the scheme, which are signature shares generation, signature shares combing and the final signature verification. We do not consider the step of user registration. This is because registration only needs to be performed only once when a user attempts to join the group. The time-consuming operations of the system are mainly signature synthesis and verification. The computation overhead comparison is described as the Table 4.

Table 4. Comparison of computation overhead

Generally speaking, $T_{\exp }$ is the most time consuming operation, followed by $T_{inv}$. The operation execution time rankings are usually as follows:

$$ T_{\exp } > T_{inv} > T_{mul} > T_{add} > T_{sub} . $$

Although in the two stages of signature combining and signature verification, Yage et al. [4] takes less time. For the signature shares generation, the proposed scheme consumes less time than Yage et al. [4], which includes the inversion operation. Shen et al. [21] mainly contains the modular multiplication and modular addition operations without modular exponentiation operation, which seems more efficient than the proposed one. But during the process of user registration and the following steps, the method involves bilinear pairing operations which will take more time. That is because a bilinear pair operation is slightly equal to 50 exponentiation operations in general. The performance of the proposed scheme is inferior to Lipeng et al. [15] in the signature shares combining and the final signature verification, but the proposed one can take the user identities as input during registration, which simplifies the key management process for users.

In real-world scenarios, the effectiveness of the proposed scheme depends on the expression execution time and the communication overhead. According to the description of the proposed algorithm, we can know that the communication overhead mainly comes from user registration, signature shares generating, signature shares combing and signature verification. For simplicity, the two steps of signature shares generating and signature shares combing are combined in one step which is denoted as signatures generating. Assuming $\left| {\varsigma } \right|$ is the size of an element in ${\mathbf{Z}}_{p}^{*}$, $\left|\Gamma \right|$ is the size of the message m, $\left|\upeta \right|$ is the size of user identification and the length of $E_{{PK_{{U_{i} }} }} (y_{i} )$ is $\left| {\varsigma } \right|$ during the process of user registration, communication overhead of the proposed scheme is shown as Table 5.

Table 5. Communication overhead of the proposed scheme

5.3 Experimental Results

In this subsection, we will evaluate the performance of the proposed scheme with several experiments. The details of the running environment are as following:

Hardware

CPU: Intel(R) Core(TM) i5-7500 CPU @ 3.40 GHz 3.40 GHz; RAM: 8.00 GB.

Software

OS: Windows 7 64; MyEclipse: 2015 CI; JAVA: 1.7.

Specifically, we will run the test 10 times and calculate the average value to eliminate errors. The running time of each step varies with $N$ and $t$ which will be recorded. The details are shown in Table 6, and the time measurement unit is milliseconds (ms).

Table 6. Execution time between different phases varying from N and t.

From the data in the table, as N and t increase, the running time of the setup phase and the signature verification phase remains almost unchanged. The experimental results show that these two steps have no direct correlation with N and t, which is consistent with the implementation. We can also know the registration phase consumes most of the time, followed by the signature shares combing phase. That is because the two steps consist a lot of modular exponentiation operations and modular inverse operations which is demonstrated in Table 4.

Figure 1 shows the execution time of the five steps when N is 20 and t is 10. We can know that the registration phase takes most of the overall running time of the system, almost 90%. It also shows that the step is the bottleneck of the overall performance, which denotes that we should focus on this step if we want to optimize the performance of the proposed algorithm.

Fig. 1.

Execution time of different steps

6 Conclusion

The paper proposes an identity-based threshold group signature scheme, which can not only simplify the process of key management, but also allow tracing the user identities. To protect the user privacy, the scheme blinds the user identities and stores them on the blockchain to prevent the malicious members from tampering with the content. Security analysis shows that the proposed signature, whose difficulty is equivalent to solve the discrete logarithm problem, achieves a high level of anonymity and can resist impersonation attacks. Computational complexity analysis shows that the new method with low computation overhead and high communication efficiency can be effectively adapted to the e-commerce scenario.