Advertisement
Browse Subject Areas
?

Click through the PLOS taxonomy to find articles in your field.

For more information about PLOS Subject Areas, click here.

  • Loading metrics

Open Access

Peer-reviewed

Research Article

An enhanced pairing-free certificateless directed signature scheme

  • Kaiqin Yang

    Roles Conceptualization, Data curation, Formal analysis, Funding acquisition, Investigation, Methodology, Project administration, Resources, Software, Supervision, Validation, Visualization, Writing – original draft, Writing – review & editing

    yangkaiqin2021@163.com

    Affiliation School of Control Science and Engineering, Shandong University, Jinan, Shandong, China

    ⨯

Abstract

Directed signature is a special cryptographic technique in which only the verifier designated by the signer can verify the validity of the signature. Directed signature can effectively protect the privacy of the signer’s identity, so it is very suitable for medical records, taxation, and other fields. To improve the security and performance of the directed signature scheme, Gayathri et al. proposed the first certificateless directed signature (CLDS) scheme without bilinear pairing and claimed that their CLDS scheme could withstand Type I and Type II attacks. In this article, we provide two attack methods to assess the security of their CLDS scheme. Unfortunately, our results indicate that their CLDS scheme is insecure against Type I and Type II attacks. That is, their CLDS scheme does not meet the unforgeability and cannot achieve the expected security goals. To resist these attacks, we present an improved CLDS scheme and give the security proof. Compared with similar schemes, our scheme has better performance and higher security.

Citation: Yang K (2022) An enhanced pairing-free certificateless directed signature scheme. PLoS ONE 17(2): e0263943. https://doi.org/10.1371/journal.pone.0263943

Editor: Pandi Vijayakumar, University College of Engineering Tindivanam, INDIA

Received: November 11, 2021; Accepted: January 29, 2022; Published: February 17, 2022

Copyright: © 2022 Kaiqin Yang. This is an open access article distributed under the terms of the Creative Commons Attribution License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original author and source are credited.

Data Availability: All relevant data are within the paper and its Supporting information files.

Funding: The author(s) received no specific funding for this work.

Competing interests: The authors have declared that no competing interests exist.

1 Introduction

Digital signature is one of the most important technologies for ensuring data security in insecure communication networks [1–3]. It can solve the problems of forgery, denial, impersonation and tampering. Digital signature provides trusted identity authentication [4] and data exchange services [5], so it is widely employed in smart city [6], smart transportation [7, 8], smart medicine [9, 10], smart grid [11] and other fields [12]. In traditional digital signature schemes, anyone can verify the signature’s validity by using the signer’s public key. However, in some practical circumstances (such as hospitals, shopping malls), the user’s public key is the private information that symbolizes the user’s identity. For example, patients do not want their health information shared with anybody other than their doctors, and consumers do not want their shopping information shared with anyone else. This requires that the user’s signature does not support public verification [13–15].

To accomplish these security functionalities, directed signature is introduced as a new signature technology [16]. Directed signature allows the signer to control the verifier of his or her signature. On the one hand, only the designated verifier can decide whether the signature is legitimate, while others can only check the signature’s validity with the signer’s or designated verifier’s help. On the other hand, when a disputed message occurs, the legitimacy of the signature can be proved to the third party by the signer and the designated verifier. On the basis of ordinary signature, directed signature adds the feature of safeguarding the signer’s identity privacy, preventing any third party from directly verifying the signature using the signer’s public key. As a result, directed signature is well suited to real scenarios in which the signer’s identity anonymity is required [17–19].

Since Lim and Lee [16] introduced the concept of directed signature, some directed signature schemes [20–22] based on the framework of public key infrastructure have been presented. However, these schemes require huge computational and communication overhead to manage certificates. Identity-based directed signature [23–25] does not require a certificate to authenticate the user’s public key, but a trusted key generation center (KGC) is required to produce a private key for the user. As a result, the key escrow problem exists in the identity-based directed signature scheme. In other words, KGC has the ability to sign any message on behalf of the user. To address these issues, certificateless directed signature (CLDS) is presented [26]. In CLDS, the user’s private key is created independently by a semi-trusted KGC and the user, so that KGC cannot obtain the user’s final private key. CLDS combines the benefits of both certificateless signature [27] and directed signature, making it more suitable for insecure communication network environments [28].

The first CLDS scheme was presented by Wan [26], but their scheme has poor computational performance because of the time-consuming bilinear pairing operation. To achieve high efficiency, Gayathri et al. [29] constructed a pairing-free CLDS scheme in 2021 and proved that their CLDS scheme is unforgeable against Type I and Type II attacks in the random model. However, in this article, we give two attack methods to prove that their CLDS scheme is insecure against Type I and Type II attackers. Specifically, both dishonest users and malicious KGC have the capacity to forge the legal signature of any message. This demonstrates that their CLDS scheme is riddled with security issues.

1.1 Our contribution

The following is a brief summary of our work.

  1. We show that the CLDS scheme proposed by Gayathri et al. [29] cannot withstand Type I attackers by using an attack approach.
  2. We show that Gayathri et al.’s CLDS scheme [29] is vulnerable to Type II attackers by employing another attack approach.
  3. To improve security, we provide an enhanced CLDS scheme.
  4. We give the security proof of the modified scheme. Furthermore, according to the results of the analysis, our scheme outperforms similar schemes in terms of performance and security.

1.2 Organization

The remainder of this article is structured in the following manner. Section 2 introduces some necessary preliminaries. Section 3 describes Gayathri et al.’s CLDS scheme [29] and analyzes its security in Section 4. Section 5 presents our improved CLDS scheme, as well as its security proof and performance analysis. Finally, the article’s conclusions are presented in Section 6.

2 Preliminaries

2.1 Elliptic curve group

Assume that Fp is a finite field. The equation y2 = x3 + ax + b defines an elliptic curve E on Fp that meets the condition 4a3 + 27b2 ≠ 0, where a, b ∈ Fp. Let O be an infinite point of E. G = {(x, y)∈E: x, y ∈ Fp}∪{O} is an additive elliptic curve cyclic group [30].

The security of Gayathri et al.’s CLDS scheme [29] is based on the following elliptic curve discrete logarithm problem (ECDLP).

Given xP ∈ G, the ECDLP is to calculate , where P is a generator of G.

2.2 Definition and security model of the CLDS scheme

As defined in [29], a CLDS scheme is composed of the following six algorithms.

  1. Setup: On input a security parameter η, this algorithm is executed by KGC and outputs the master secret key and public parameters params.
  2. Partial Secret Key Gen: On input an identity IDi, this algorithm is executed by KGC and outputs a partial private key Di.
  3. User Key Gen: The user runs this algorithm to generate its public key PKi and secret key SKi.
  4. Signature Generation: Given a message m and a public key PKV of a designated verifier, a signer uses its secret key SKS and public key PKS to generate a signature σ of m.
  5. Direct Verification: On input a signature σ of m and the signer’s public key-identity pair (PKS, IDS), the designated verifier uses its secret key SKV to check the validity of the signature. This algorithm outputs accept if σ is legal; otherwise, it outputs reject.
  6. Public Verification: Given a signature σ of m, a value Aid calculated by the signer or the designated verifier, the signer’s public key-identity pair (PKS, IDS) and the designated verifier’s public key-identity pair (PKV, IDV), this algorithm outputs accept if σ is legal; otherwise, it outputs reject.

As discussed in [26, 29], a secure CLDS scheme must resist the following two types of attackers.

  1. Type I Attacker : It is an external adversary who can launch the public key replacement attack on any user. However, cannot obtain KGC’s master secret key.
  2. Type II Attacker : It is a malicious KGC that can create the partial private key of any user and modify the values of system parameters, but cannot replace the user’s public key and obtain the user’s secret key.

To describe the unforgeability of a CLDS scheme, the following oracles are defined by security games between the challenger and the adversary.

  • Reveal Partial Secret Key Oracle : On receiving an identity IDi from the adversary, the challenger obtains Di by running the Partial Secret Key Gen algorithm and returns it to the adversary.
  • Create User Oracle : When receiving an identity IDi from the adversary, the challenger obtains a public key PKi by running the User Key Gen algorithm and returns it to the adversary.
  • Reveal Secret Key Oracle : On receiving an identity IDi from the adversary, the challenger obtains a secret key SKi by running the User Key Gen algorithm and returns it to the adversary.
  • Replace Public Key Oracle : On receiving a tuple from from the adversary, the challenger replaces (xi, PKi) of IDi with , respectively.
  • Sign Oracle : When receiving two identities (IDS, IDV) and a message m from the adversary, the challenger obtains a signature σ of m by running the Signature Generation algorithm and returns it to the adversary.
  • D. Verify Oracle : When receiving two identities (IDS, IDV), a message m and a signature σ from the adversary, the challenger runs the Direct Verification algorithm and returns the corresponding output to the adversary.
  • P. Verify Oracle : When receiving two identities (IDS, IDV), a message m and a signature σ from the adversary, the challenger runs the Public Verification algorithm and returns the corresponding output to the adversary.

Game 1: The adversary in this game is a Type I attacker .

  • Initialization Phase: The challenger runs the Setup algorithm and sends params to .
  • Queries Phase: is allowed to adaptively query seven oracles , , , , , and .
  • Forgery Phase: Eventually, outputs a tuple . wins in this game if σ* is a valid signature on m* under and , and the following conditions hold.
    1. The oracle has never been involved for .
    2. The oracle has never been involved for .

Game 2: The adversary in this game is a Type II attacker .

  • Initialization Phase: runs the Setup algorithm, and sends the master secret key and params to the challenger.
  • Queries Phase: is allowed to adaptively query the oracles , , , and .
  • Forgery Phase: Eventually, outputs a tuple . wins in this game if σ* is a valid signature on m* under and , and the following conditions hold.
    1. The oracle has never been involved for .
    2. The oracle has never been involved for .

Definition 1. A CLDS scheme is said to be existentially unforgeable, if there is no polynomial time attacker ( and ) can win in the above two games with a non-negligible probability.

3 Review of Gayathri et al.’s CLDS scheme

In this section, Gayathri et al.’s CLDS scheme [29] is briefly described as follows.

  1. Setup: KGC selects an elliptic curve group G of prime order q and a generator P. Then, KGC randomly selects , calculates Ppub = sP, and sets the master secret key as msk = s. Next, KGC selects three hash functions . Finally, KGC publicly broadcasts the parameters params = {G, q, P, H1, H2, H3, Ppub}.
  2. Partial Secret Key Gen: Given the identity IDi of a user, KGC does as follows.
    1. Select at random and calculate Ri = ri P.
    2. Calculate h1i = H1(IDi, Ri, Ppub).
    3. Calculate di = ri + h1i s mod q.
    4. Send the partial private key Di = (Ri, di) to the user secretly.
    5. After receiving Di from KGC, the user checks the validity of its partial private key through the following equation.
  3. User Key Gen: A user with identity IDi does as follows.
    1. Select randomly and calculate Xi = xi P.
    2. Set its secret key as SKi = (xi, di).
    3. Set its public key as PKi = (Xi, Ri).
  4. Signature Generation: Given the public key PKV and identity IDV of a designated verifier, a signer with identity IDS performs the following operations to sign a message m.
    1. Select randomly, and calculate US = t1 P and VS = t2 P.
    2. Calculate WS = US + t2 XV.
    3. Calculate h2 = H2(m, IDS, IDV, US, RS) and h3 = H3(m, IDS, IDV, US, RS, h2) by using its identity IDS and public key PKS = (XS, RS).
    4. Calculate kS = h2 dS + h3 t2 + h2 xS mod q by using its secret key SKS = (xS, dS).
    5. Set σS = (kS, WS, VS) as the signature of m.
  5. Direct Verification: After receiving a signature σS = (kS, WS, VS) on a message m from a signer with identity IDS, a designated verifier with identity IDV performs the following operations to verify the validity of the signature.
    1. Calculate YV = WS − xV VS = US by using its secret key SKV = (xV, dV).
    2. Calculate h2 = H2(m, IDS, IDV, YV, RS).
    3. Calculate h3 = H3(m, IDS, IDV, YV, RS, h2).
    4. Verify the following signature verification equation.
      If it holds, σS is valid and accepted by the verifier; else, the verifier rejects σS.
  6. Public Verification: Given a signature σS = (kS, WS, VS) on a message m under two identities IDS and IDV, any third party does as follows.
    1. Obtain the value Aid = US = YV calculated by the signer with IDS or the verifier with IDV.
    2. Calculate h2 = H2(m, IDS, IDV, Aid, RS).
    3. Calculate h3 = H3(m, IDS, IDV, Aid, RS, h2).
    4. Verify the following signature verification equation.
      If it holds, σS is valid; else, σS is invalid.

4 Security analysis of Gayathri et al.’s CLDS scheme

In [29], Gayathri et al. claimed that their CLDS scheme could withstand Type I and Type II attackers. In this section, we give two concrete attack methods to prove that their CLDS scheme is insecure against Type I and Type II attacks. As a result, their CLDS scheme has serious security weaknesses.

4.1 Type I attack

A Type I attacker selects a target user whose identity and public key are IDS and PKS = (XS, RS), respectively. can forge the valid signature of any selected message by replacing the public key of the target user. Let the identity and public key of the designated verifier be IDV and PKV = (XV, RV), respectively. initiates the following attack operations.

  1. Calculate h1S = H1(IDS, RS, Ppub).
  2. Randomly select and calculate
  3. Replace the previous public key PKS of the target user with the new public key .
  4. Randomly select , and calculate , and .
  5. Select a message m*, and calculate and .
  6. Calculate .
  7. Output as a forged signature of m*.

The following equation shows that the signature forged by is considered valid and accepted by the verifier with identity IDV, because

Then, we have

Therefore, the forged signature meets the signature verification equation in the Direct Verification algorithm. During the above-mentioned attack, does not gain any knowledge about the target user’s partial private key. That is, ’s attack against the CLDS scheme of Gayathri et al. [29] is successful. As a result, Gayathri et al.’s CLDS scheme [29] is insecure against Type I attacks.

4.2 Type II attack

Assume that IDS and PKS = (XS, RS) are the identity and public key of the target user attacked by a Type II attacker , respectively. Let the identity and public key of the designated verifier be IDV and PKV = (XV, RV), respectively. knows the master secret key s, so can calculate the target user’s partial private key and modify system parameters. performs the following attack operations to forge the valid signature of any message.

  1. Randomly select and calculate
  2. Replace the previous value RS with the new value .
  3. Calculate .
  4. Select randomly, and calculate , and .
  5. Select a message m′, and calculate and .
  6. Calculate .
  7. Output as a forged signature of m′.

The signature forged by is considered legal and accepted by the verifier whose identity is IDV, because

It is easy to derive the following equation from the above equation.

This demonstrate that the forged signature satisfies the signature verification equation in the Direct Verification algorithm. In the above attack, the secret key xS of the target user is unknown to . Therefore, ’s forgery attack against the CLDS scheme of Gayathri et al. [29] is successful. In other words, Gayathri et al.’s CLDS scheme [29] is also insecure against Type II attacks.

5 Our improved CLDS scheme

The reason why Gayathri et al.’s CLDS scheme [29] cannot resist the public key replacement attack is that does not require the target user’s partial private key for forging the signature. Furthermore, the reason why Gayathri et al.’s CLDS scheme [29] cannot withstand Type II attacks is that avoids the target user’s secret key by changing the value RS.

5.1 Our construction

To resist the two types of forgery attacks, we modify the CLDS scheme of Gayathri et al. [29] as follows.

  1. The Setup algorithm is the same as the corresponding algorithm in the original scheme, and the only difference is to add a hash function .
  2. The algorithms Partial Secret Key Gen and User Key Gen are the same as the corresponding algorithms in the original scheme.
  3. In the Signature Generation algorithm, a value h4 = H4(m, IDS, IDV, US, VS, PKS, PKV, h2) is added, and the values of h2 and h3 are modified to two new values h2 = H2(m, IDS, IDV, US, VS, Ppub) and h3 = H3(m, IDS, IDV, US, VS, h2) respectively. The corresponding value kS is modified to and the signature of a message m is σS = (kS, WS, VS).
  4. The algorithms Direct Verification and Public Verification are the same as the corresponding algorithms in the original scheme. The only difference is that the verifier needs to calculate h2, h3 and h4, and verifies σS by using the following equation:

Correctness:

5.2 Security proof

In our CLDS scheme, adequate redundant values are added to the input parameters of the three hash functions h2, h3 and h4. By altering some public values, Type I and Type II attackers will be unable to forge valid signatures. The following theorems 1 and 2 provide the security proof for the improved CLDS scheme.

Theorem 1. If the ECDLP is intractable, then our improved CLDS scheme is unforgeable against Type I attacks.

Proof. Let be a Type I attacker. If can forge a legal signature of the improved scheme, then we construct an algorithm that can solve the ECDLP. Note that serves as the challenger in Game 1 (as stated in Section 2.2). Suppose that obtains an ECDLP instance (P, αP). To calculate the unknown by using the forgery of , plays the following interactive game with .

  • Initialization Phase: generates system parameters params = {G, q, P, H1, H2, H3, Ppub} by executing the Setup algorithm, where Ppub = αP. The assignment of Ppub indicates that the master secret key is α, but does not know α. Then, selects a target user’s identity ID*, and sends params to .
  • Queries Phase: responds to ’s various queries by establishing the following oracles.
    • H1 Oracle : creates a list L1 of tuple (IDi, Ri, Ppub, h1i) whose initial value is empty. When initiates a query H1(IDi, Ri, Ppub), returns h1i to if L1 contains the tuple (IDi, Ri, Ppub, h1i). Otherwise, randomly selects , adds (IDi, Ri, Ppub, h1i) to L1, and returns h1i to .
    • H2 Oracle : creates a list L2 of tuple (mi, IDi, IDj, Ui, Vi, Ppub, h2i) whose initial value is empty. When initiates a query H2(mi, IDi, IDj, Ui, Vi, Ppub), returns h2i to if L2 contains the tuple (mi, IDi, IDj, Ui, Vi, Ppub, h2i). Otherwise, randomly selects , adds (mi, IDi, IDj, Ui, Vi, Ppub, h2i) to L2, and returns h2i to .
    • H3 Oracle : creates a list L3 of tuple (mi, IDi, IDj, Ui, Vi, h2i, h3i) whose initial value is empty. When initiates a query H3(mi, IDi, IDj, Ui, Vi, h2i), returns h3i to if L3 contains the tuple (mi, IDi, IDj, Ui, Vi, h2i, h3i). Otherwise, randomly selects , adds (mi, IDi, IDj, Ui, Vi, h2i, h3i) to L3, and returns h3i to .
    • H4 Oracle : creates a list L4 of tuple (mi, IDi, IDj, Ui, Vi, PKi, PKj, h2i, h4i) whose initial value is empty. When initiates a query H4(mi, IDi, IDj, Ui, Vi, PKi, PKj, h2i), returns h4i to if L4 contains the tuple (mi, IDi, IDj, Ui, Vi, PKi, PKj, h2i, h4i). Otherwise, randomly selects , adds (mi, IDi, IDj, Ui, Vi, PKi, PKj, h2i, h4i) to L4, and returns h4i to .
    • Reveal Partial Secret Key Oracle : creates a list LPSK of tuple (IDi, di, Ri, ri) whose initial value is empty. returns Di = (Ri, di) to if LPSK contains the tuple (IDi, di, Ri, ri). Otherwise, executes as follows.
      1. If IDi = ID*, randomly selects , sets d* = ⊥, calculates R* = r* P, adds (ID*, d*, R*, r*) to LPSK, and returns D* = (d*, R*) to .
      2. If IDi ≠ ID*, randomly selects , calculates Ri = di P − h1i Ppub, adds (IDi, Ri, Ppub, h1i) to L1, records (IDi, di, Ri, ri) in LPSK, and returns Di = (Ri, di) to .
    • Create User Oracle : creates a list LUSER of tuple (IDi, xi, Xi, SKi, PKi) whose initial value is empty. When receiving an identity IDi from , returns PKi to if LUSER contains the tuple (IDi, xi, Xi, SKi, PKi). Otherwise, randomly selects , retrieves di and Ri from the tuple (IDi, di, Ri, ri) in LPSK, calculates Xi = xi P, sets SKi = (xi, di) and PKi = (Xi, Ri), adds (IDi, xi, Xi, SKi, PKi) to LUSER, and returns PKi to .
    • Reveal Secret Key Oracle : On receiving an identity IDi from , finds the tuple (IDi, xi, Xi, SKi, PKi) from LUSER to recover SKi, and then returns SKi to .
    • Replace Public Key Oracle : On receiving a tuple from , looks for the tuple (IDi, xi, Xi, SKi, PKi) from LUSER, and then replaces xi and PKi with and , respectively.
    • Sign Oracle : When receiving two identities (IDi, IDj) and a message mi from , does as follows.
      1. If IDi ≠ ID*, runs the algorithm Signature Generation to produce a signature σi = (ki, Wi, Vi) of mi, and returns it to .
      2. If IDi = ID*, randomly selects , searches the tuple (ID*, x*, X*, SK*, PK*) in LUSER to recover PK* = (X*, R*), looks for the tuple (IDj, xj, Xj, SKj, PKj) in LUSER to retrieve xj and PKj = (Xj, Rj), and finds the tuple in L1 to retrieve . Then, calculates Wi = ti P, and Ui = Wi − xj Vi, sets σi = (ki, Wi, Vi), and sends the signature σi to . Finally, records (mi, IDi, IDj, Ui, Vi, Ppub, h2i), (mi, IDi, IDj, Ui, Vi, h2i, h3i) and (mi, IDi, IDj, Ui, Vi, PKi, PKj, h2i, h4i) in lists L2, L3 and L4, respectively.
    • D. Verify Oracle : When receiving two identities (IDi, IDj), a message mi and a signature σi from , runs the algorithm Direct Verification and returns the corresponding output to .
    • P. Verify Oracle : When receiving two identities (IDi, IDj), a message mi and a signature σi from , runs the algorithm Public Verification and returns the corresponding output to .
  • Forgery Phase: Finally, outputs a legal signature for a message under the target user’s identity ID* and public key PK*. According to Forking Lemma [31], uses the same random tape to replay and assigns a different value to the hash function H2, then generates another signature of that satisfies , and . Since and are two legal signatures, we get the following equations. (1) (2)
    From Eqs (1) and (2), we have (3) (4)
    Thus, we use Eqs (3) and (4) to calculate (5)
    From Eq (5), we can get the solution α of the given ECDLP instance. However, ECDLP is a difficult problem that cannot be solved in polynomial time, so it can be inferred that the above forgery attack initiated by is not feasible. Therefore, our improved CLDS scheme is unforgeable against the Type I attacker.

Theorem 2. If the ECDLP is intractable, then our improved CLDS scheme is unforgeable against Type II attacks.

Proof. Let be a Type II attacker. If can forge a legal signature of the improved scheme, then we construct an algorithm that can solve the ECDLP. Note that acts as the challenger in Game 2 (as defined in Section 2.2). Suppose that obtains an ECDLP instance (P, αP). To calculate the unknown by using the forgery of , plays the following interactive game with .

  • Initialization Phase: randomly selects , calculates Ppub = sP, and sets s as the master secret key. Then, executes the Setup algorithm to produce system parameters params. Finally, sends params and s to . Let ID* is the identity of the target user selected by .
  • Queries Phase: responds to ’s various queries by establishing the following oracles.
    • The oracles , , and are the same as in Theorem 1.
    • Create User Oracle : creates a list LUSER of tuple (IDi, di, Ri, xi, Xi, SKi, PKi) whose initial value is empty. When receiving an identity IDi from , returns PKi to if LUSER contains the tuple (IDi, di, Ri, xi, Xi, SKi, PKi). Otherwise, runs the algorithm Partial Secret Key Gen to create a partial private key Di = (Ri, di), and then performs the following operations.
      1. If IDi = ID*, sets x* = ⊥ and X* = αP. Then, sets SK* = (x*, d* = di) and PK* = (X*, R* = Ri). Next, adds (ID*, d*, R*, x*, X*, SK*, PK*) to LUSER, and returns PK* to .
      2. If IDi ≠ ID*, randomly selects , calculates Xi = xi P, sets SKi = (xi, di) and PKi = (Xi, Ri), adds (IDi, di, Ri, xi, Xi, SKi, PKi) to LUSER, and returns PKi to .
    • Reveal Secret Key Oracle : On receiving an identity IDi from , finds the tuple (IDi, di, Ri, xi, Xi, SKi, PKi) from LUSER to recover SKi, and then returns SKi to .
    • Sign Oracle : creates a list LSig of tuple (mi, IDi, ID*, Vi, Wi, t2i) whose initial value is empty. When receiving two identities (IDi, IDj) and a message mi from , does as follows.
      1. If IDi ≠ ID* and IDj ≠ ID*, runs the algorithm Signature Generation to produce a signature σi = (ki, Wi, Vi) of mi.
      2. If IDi ≠ ID* and IDj = ID*, randomly selects and calculates Ui = t1i P, Vi = t2i P and Wi = Ui − t2i X*. Then, runs the algorithm Signature Generation to generate a signature σi = (ki, Wi, Vi) of mi. Finally, records (mi, IDi, ID*, Vi, Wi, t2i) in LSig.
      3. If IDi = ID* and IDj ≠ ID*, randomly selects , searches the tuple (ID*, d*, R*, x*, X*, SK*, PK*) in LUSER to recover PK* = (X*, R*), looks for the tuple (IDj, dj, Rj, xj, Xj, SKj, PKj) in LUSER to retrieve xj and PKj = (Xj, Rj), and finds the tuple in L1 to retrieve . Then, calculates Wi = ti P, and Ui = Wi − xj Vi, and sets σi = (ki, Wi, Vi).
      4. If IDi = ID* and IDj = ID*, randomly selects , searches the tuple (ID*, d*, R*, x*, X*, SK*, PK*) in LUSER to recover PK* = (X*, R*), and finds the tuple in L1 to retrieve . Then, calculates Wi = ti P, and Ui = Wi − t2i X*, and sets σi = (ki, Wi, Vi). Finally, records (mi, ID*, ID*, Vi, Wi, t2i) in LSig.

      sends the final signature σi to . Moreover, records (mi, IDi, IDj, Ui, Vi, Ppub, h2i), (mi, IDi, IDj, Ui, Vi, h2i, h3i) and (mi, IDi, IDj, Ui, Vi, PKi, PKj, h2i, h4i) in lists L2, L3 and L4, respectively.
    • D. Verify Oracle : When receiving two identities (IDi, IDj), a message mi and a signature σi from , determines whether IDj = ID*. If it holds, finds the tuple (mi, IDi, ID*, Vi, Wi, t2i) from LSig to extract t2i and calculates Yi = Ui = Wi − t2i X*. Then, runs the algorithm Direct Verification and returns the corresponding output to .
    • P. Verify Oracle : When receiving two identities (IDi, IDj), a message mi and a signature σi from , determines whether IDj = ID*. If it holds, finds the tuple (mi, IDi, ID*, Vi, Wi, t2i) from LSig to extract t2i and calculates Aidi = Yi = Ui = Wi − t2i X*. Then, runs the algorithm Public Verification and returns the corresponding output to .
  • Forgery Phase: Finally, outputs a legal signature for a message under the target user’s identity ID* and public key PK*. According to Forking Lemma [31], uses the same random tape to replay and assigns a different value to the hash function H4, then generates another signature of that satisfies , . Since and are two legal signatures, we get the following equations. (6) (7)
    From Eqs (6) and (7), we have (8) (9)
    Thus, we utilize Eqs (8) and (9) to calculate (10)
    From Eq (10), we can obtain the solution α of the given ECDLP instance. Since ECDLP is a hard mathematical problem, the aforementioned forgery attack initiated by is not feasible. Therefore, our improved CLDS scheme is unforgeable against the Type II attacker.

5.3 Performance analysis

We evaluate the computational and communication costs of the enhanced CLDS scheme and similar schemes. The execution time of various cryptographic operations is given in [32], and a summary of all operations is shown in S1 Table. In the following performance comparisons, we don’t consider modular multiplication and modular addition in because their computational overhead is so negligible.

In Azees et al.’s scheme [4] and Ahamed et al.’s scheme [7], the computational cost of calculating a signature is TSM + TH = 0.167001 ms, whereas the computational cost of verifying a signature is 2TP + TSM + TAdd + TH = 9.050491 ms. Hence, the total computational overhead is 9.217492 ms. These two schemes [4, 7] have high signature generation efficiency. Unfortunately, none of them are CLDS schemes.

In Wan et al.’s CLDS scheme [26], the computational overhead of the algorithm Signature Generation is 5TSM + TP + 2TMTP + 2TH + TAdd = 5.557464 ms, the computational overhead of the algorithm Direct Verification is 3TP + 2TMTP + 2TH = 13.612061 ms, whereas the computational overhead of the algorithm Public Verification is 2TP + TMTP + 2TH = 9.028336 ms. Hence, the total computational overhead is 28.197861 ms.

In Gayathri et al.’s CLDS scheme [29], the computational overhead of the algorithm Signature Generation is 3TSM + 2TH + TAdd = 0.500623 ms, the computational overhead of the algorithm Direct Verification is 5TSM + 3TH + 4TAdd = 0.837053 ms, whereas the computational overhead of the algorithm Public Verification is 5TSM + 3TH + 3TAdd = 0.835649 ms. Hence, the total computational overhead is 2.173325 ms.

In our CLDS scheme, the computational overhead of the algorithm Signature Generation is 3TSM + 3TH + TAdd = 0.502407 ms, the computational overhead of the algorithm Direct Verification is 6TSM + 4TH + 4TAdd = 1.004054 ms, whereas the computational overhead of the algorithm Public Verification is 6TSM + 4TH + 3TAdd = 1.002650 ms. Hence, the total computational overhead is 2.509111 ms.

The comparison results of the computational overhead between our CLDS scheme and the other CLDS schemes are shown in S1 Fig. As shown in S1 Fig, the computational cost of our scheme is less than that of Wan et al.’s scheme [26], and is almost equal to that of Gayathri et al.’s scheme [29]. However, we demonstrate in Section 4 that Gayathri et al.’s scheme [29] is insecure, and that our enhanced CLDS scheme can withstand Type I and II forgery attacks.

Similar to the evaluation of communication overhead in [32], a bilinear pairing e: G1 × G1 → G2 is selected, where the length of an element in G1 is 1024 bits. In the elliptic curve cryptosystem, the length of the prime number q is 160 bits, while the length of an element in the group G is 320 bits. The signature length of Azees et al.’s scheme [4] is |G1| = 1024 bits = 128 bytes, the signature length of Ahamed et al.’s scheme [7] is |G1| = 128 bytes, the signature length of Wan et al.’s scheme [26] is 4|G1| = 4 × 1024 = 4096 bits = 512 bytes, the signature length of Gayathri et al.’s scheme [29] is 2|G| + |q| = 2 × 320 + 160 = 800 bits = 100 bytes, whereas the signature length of our scheme is also 2|G| + |q| = 100 bytes. Obviously, our CLDS scheme has shorter signature length than other schemes [4, 7, 26]. The comparison results of the communication overhead of the three CLDS schemes are given in S2 Fig. Therefore, our CLDS scheme has better performance and higher security.

6 Conclusions

Directed signature can ensure data security as well as the signer’s identity privacy, so it is very suitable for practical applications such as medical records and tax information. Gayathri et al. [29] devised and proved the first pairing-free CLDS scheme. However, in this article, we analyze the security of their CLDS scheme and find that their scheme is insecure against Type I and Type II attackers. Therefore, their CLDS scheme suffers from significant security flaws. To address the security issues, we give an enhanced CLDS scheme. The results of comparison with related schemes show that our scheme has higher security while keeping the original scheme’s performance, so it is more suitable for practical scenarios.

Supporting information

S1 Data.

https://doi.org/10.1371/journal.pone.0263943.s001

(XLSX)

S1 Table. The execution time of cryptographic operations.

https://doi.org/10.1371/journal.pone.0263943.s002

(PDF)

S1 Fig. Comparison of the computational cost of CLDS schemes.

https://doi.org/10.1371/journal.pone.0263943.s003

(PDF)

S2 Fig. Comparison of communication overhead of CLDS schemes.

https://doi.org/10.1371/journal.pone.0263943.s004

(PDF)

References

  1. 1. Kumar P, Kumari S, Sharma V, Sangaiah AK, Wei J, Li X (2018) A certificateless aggregate signature scheme for healthcare wireless sensor network. Sustainable Computing-Informatics and Systems 18: 80–89.
  2. 2. Chang J, Ji Y, Shao B, Xu M, Xue R (2020) Certificateless homomorphic signature scheme for network coding. IEEE/ACM Transactions on Networking 28: 2615–2628.
  3. 3. Mundhe P, Yadav VK, Singh A, Verma S, Venkatesan S (2020) Ring signature-based conditional privacy-preserving authentication in VANETs. Wireless Personal Communications 114: 853–881.
  4. 4. Azees M, Vijayakumar P, Deboarh LJ (2017) EAAP: Efficient anonymous authentication with conditional privacy-preserving scheme for vehicular ad hoc networks. IEEE Transactions on Intelligent Transportation Systems 18(9): 2467–2476.
  5. 5. Vijayakumar P, Azees M, Kannan A, Deborah LJ (2015) Dual authentication and key management techniques for secure data transmission in vehicular ad hoc networks. IEEE Transactions on Intelligent Transportation Systems 17(4): 1015–1028.
  6. 6. Jegadeesan S, Azees M, Kumar PM, Manogaran G, Chilamkurti N, Varatharajan R, Hsu CH (2019) An efficient anonymous mutual authentication technique for providing secure communication in mobile cloud computing for smart city applications. Sustainable Cities and Society 101522: 1–7.
  7. 7. Ahamed A B S, Kanagaraj N, Azees M (2018) EMBA: An efficient anonymous mutual and batch authentication schemes for vanets. In: Proc. 2018 Second International Conference on Inventive Communication and Computational Technologies. pp. 1320–1326.
    • 8. Maria A, Pandi V, Lazarus JD, Karuppiah M, Christo MS (2021) BBAAS: Blockchain-based anonymous authentication scheme for providing secure communication in VANETs. Security and Communication Networks 6679882: 1–11.
    • 9. Azees M, Vijayakumar P, Karuppiah M, Nayyar A (2021) An efficient anonymous authentication and confidentiality preservation schemes for secure communications in wireless body area networks. Wireless Networks 27(3): 2119–2130.
    • 10. Xu Z, He D, Vijayakumar P, Choo KKR, Li L (2020) Efficient NTRU lattice-based certificateless signature scheme for medical cyber-physical systems. Journal of medical systems 44(5): 1–8. pmid:32189085
    • 11. Kong W, Shen J, Vijayakumar P, Cho Y, Chang V (2020) A practical group blind signature scheme for privacy protection in smart grid. Journal of Parallel and Distributed Computing 136: 29–39.
    • 12. Vijayakumar P, Obaidat MS, Azees M, Islam SH, Kumar N (2019) Efficient and secure anonymous authentication with location privacy for IoT-based WBANs. IEEE Transactions on Industrial Informatics 16(4): 2603–2611.
    • 13. Zheng M, Xue K, Li S, Yu N (2021) A practical quantum designated verifier signature scheme for E-voting applications. Quantum Information Processing 20: 1–22.
    • 14. Thorncharoensri P, Susilo W, Baek J (2020) Aggregatable certificateless designated verifier signature. IEEE Access 8: 95019–95031.
      • 15. Xin X, Wang Z, Yang Q, Li F (2020) Identity-based quantum designated verifier signature. International Journal Of Theoretical Physics 59: 918–929.
      • 16. Lim C H, Lee P J (1992) Modified Maurer-Yacobi’s scheme and its applications. In: Proc. 2017 IEEE Computing, Communication and Automation. pp. 308–323.
        • 17. Lu R, Lin X, Cao Z, Shao J, Liang X (2008) New (t, n) threshold directed signature scheme with provable security. Information Sciences 178: 756–765.
        • 18. Hwang JY, Kim HJ, Lee DH, Song B (2008) An enhanced (t, n) threshold directed signature scheme. Information Sciences 275: 284–292.
        • 19. Mohamad MSA (2020) Threshold-directed signature scheme based on hybrid number theoretic problems. Asian Journal of Mathematics 2050098: 1–10.
        • 20. Lu R, Cao Z (2006) A directed signature scheme based on RSA assumption. International Journal of Information Security 2: 182–186.
        • 21. Ismail ES, Hasan YA (2006) A directed signature scheme based on discrete logarithm problem. Jurnal Teknologi 2: 37–44.
        • 22. Ramlee NN, Ismail ES (2013) A new directed signature scheme with hybrid problems. Applications of Mathematics 125: 6217–6225.
        • 23. Ku J, Yun D, Zheng B, Wei S (2012) An efficient ID-based directed signature scheme from optimal eta pairing. In: Proc. ISICA 2012. pp. 440–448.
          • 24. Zhang J, Yang Y, Niu X (2009) Efficient provable secure ID-based directed signature scheme without random oracle. In: Proc. ISNN 2009. pp. 318–327.
            • 25. Gayathri N B, Rao R K, Reddy P V (2017) Efficient and provably secure pairing free ID-based directed signature scheme. In: Proc. ISNN 2017. pp. 28–38.
              • 26. Wan Z (2011) Certificateless directed signature scheme. In: Proc. WiCOM 2011. pp. 1–4.
                • 27. Huang X, Mu Y, Susilo W, Wong D S, Wu W (2007) Certificateless signature revisited. In: Proc. ACISP 2007. pp. 308–4322.
                  • 28. Rao RK, Gayathri NB, Reddy PV (2019) Efficient and secure certificateless directed proxy signature scheme without pairings. International Journal of Applied Mathematics and Computer Science 10: 1091–1118.
                  • 29. Gayathri NB, Gowri T, Rao RK, Reddy PV (2021) Efficient and secure pairing-free certificateless directed signature scheme. Journal of King Saud University-Computer and Information Science 33: 225–234.
                  • 30. Zhan Y, Wang B, Lu R (2020) Cryptanalysis and improvement of a pairing-free certificateless aggregate signature in healthcare wireless medical sensor networks. IEEE Internet of Things Journal 8: 5973–5984.
                  • 31. Pointcheval D, Stern J (2000) Security arguments for digital signatures and blind signatures. Journal of Cryptology 13: 361–369.
                  • 32. Liu J, Wang L, Yu Y (2020) Improved security of a pairing-free certificateless aggregate signature in healthcare wireless medical sensor networks. IEEE Internet of Things Journal 7: 5256–5266.