#### Abstract

In digital signature, strong unforgeability requires that an attacker cannot forge a new signature on any previously signed/new messages, which is attractive in both theory and practice. Recently, a strongly unforgeable certificateless signature (CLS) scheme without random oracles was presented. In this paper, we firstly show that the scheme fails to achieve strong unforgeability by forging a new signature on a previously signed message under its adversarial model. Then, we point out that the scheme is also vulnerable to the malicious-but-passive key generation center (MKGC) attacks. Finally, we propose an improved strongly unforgeable CLS scheme in the standard model. The improved scheme not only meets the requirement of strong unforgeability but also withstands the MKGC attacks. To the best of our knowledge, we are the first to prove a CLS scheme to be strongly unforgeable against the MKGC attacks without using random oracles.

#### 1. Introduction

In 1984, Shamir brought in the notion of identity-based public key cryptography [1] to avert the heavy certificate management problem in traditional certificate-based public key systems. In this scenario, a fully trusted key generation center (KGC) takes care of deriving the secret key from an entity’s public identity information (e.g., personal identity number) which is directly used as the corresponding public key. From then on, lots of efforts have been made in this area [2–4]. However, these identity-based schemes are subject to the key escrow problem; that is, the KGC owns any entity’s secret key and, therefore, can do anything on behalf of the entity whereas not being detected.

In order to avoid this problem, Al-Riyami and Paterson introduced a new notion named certificateless public key cryptography (CL-PKC) and formalized its security model [5], in which the KGC is considered as a semitrusted third party and only produces a partial secret key for an entity using its own master secret key, and each entity independently picks an extra secret value for themselves. As a consequence, the entity’s secret key consists of the partial secret key and the secret value, which make an attacker not do anything instead of the entity if the attacker just has one of the two parts. In this scenario [5], the attacks only knowing the entity’s secret value are denoted by public key replacement (PKR) attacks while the others merely obtaining the master secret key are denoted by honest-but-curious key generation center (HKGC) attacks. Before long, Au et al. addressed a malicious-but-passive key generation center (MKGC) attacks [6], in which an attacker can set some trapdoors in the system parameters adaptively rather than only being told the master secret key like in HKGC attacks. So far, CL-PKC has received many attention under those adversarial models.

As an important branch in certificateless settings, many studies have focused on certificateless signature (CLS) schemes [7–13]. Nevertheless, most of these early CLS schemes are only provably secure in the random oracle model [14], whose security may not be able to remain when the random oracle is instantiated with a concrete hash function. To fill the gap, Liu et al. proposed the first CLS scheme secure in the standard model [15] and then some modified schemes were put forward in [16–23]. Nevertheless, all of them only were proven to be secure against PKR attacks and HKGC attacks. Although some of them like [19, 22, 23] have been indicated to be secure against MKGC attacks, the authors do not provide a formal security proof under MKGC attacks without random oracles. Therefore, it is still an unresolved problem to construct a concrete CLS scheme provably secure against MKGC attacks in the standard model.

Recently, Hung et al. gave a certificateless signature scheme (HT scheme, for short) [21] and discussed its security under PKR attacks and HKGC attacks. They claimed that no attacker can forge a valid signature on a message, even given some previous signatures on the message. In other words, they stated that their scheme is strongly unforgeable under their security model. In this paper, we firstly illustrate that the HT scheme does not meet strong unforgeability as they claimed, by forging a new valid signature on any previously signed message. Further, we show that the HT scheme suffers from MKGC attacks by giving a concrete attack. At last, we propose an improved certificateless signature scheme which not only is strongly unforgeable but also resists MKGC attacks in the standard model.

This paper is organized as follows. In Section 2, we give some preliminaries. In Section 3, we review the HT scheme and present our attacks. In Section 4, we describe two building blocks based on which we then construct an improved strongly secure certificateless signature scheme in the standard model. Finally, the conclusion is given in Section 5.

#### 2. Preliminaries

##### 2.1. Bilinear Pairings and Complexity Assumption

In this paper, we adopt the standard term about bilinear pairings described in [21]. Here, () is a concrete instance, where denotes a big prime, and denote two order cyclic groups, denotes an admissible bilinear mapping , and denotes a generator in .

*Discrete Logarithm (DL) Assumption*. Given , the DL problem is to find the integer such that . If the DL problem cannot be solved in polynomial time, the DL assumption holds.

*Computational Diffie-Hellman (CDH) Assumption*. Given , the CDH problem is to compute group element . If the CDH problem cannot be solved in polynomial time, the CDH assumption holds.

##### 2.2. Collision-Resistant Hash Function (CRHF) Assumption

Let be a keyed hash family of functions indexed by . We say that algorithm has advantage in breaking the collision resistance of if where the probability is taken over the random choice of and the random bits of . Here, a hash family is -collision-resistant if no -time adversary has advantage at least in breaking the collision resistance of .

##### 2.3. Framework and Security Model

The five algorithms below which can be run in polynomial time comprise a certificateless signature scheme:(i)*Setup*: when receiving a security parameter , the algorithm outputs the master secret key and system parameters . is available for all the other algorithms.(ii)*PSKExt*: when receiving the master secret key and an entity , the algorithm outputs the partial secret key and sends it over a secure channel to the entity.(iii)*SetUKey*: when receiving an entity , this algorithm outputs the secret key and public key . Note that is composed of and , where denotes the secret value and is picked by the entity itself independently.(iv)*Sign*: when receiving an entity’s secret key and a message , this algorithm outputs a signature .(v)*Verify*: when receiving a signature , a message , and an entity public key , this algorithm outputs either “accept” or “reject” relying on the signature validity.

Like [11, 21], two types of adversaries are taken into account in the above CLS definition. The first is a public key replacement (PKR) attacker who knows the targeted entity secret value but cannot request the entity partial secret key. The other is an honest-but-curious KGC (HKGC) attacker that is allowed to obtain the master secret key but cannot know the targeted entity secret value. Here, the strong security of a CLS scheme is captured by means of Games 1 and 2 between a challenger and an attacker .

*Game 1 (for PKR attacker)*(i)* Init*: given a security parameter , invokes* Setup* to produce the master secret key and system parameters . is given to and is kept by itself.(ii)* Queries*: in this phase, runs the following queries adaptively: : receiving an entity , invokes* SetUkey* to obtain the entity public key and returns it to . : receiving a new entity public key , finds and updates the corresponding item for the entity . : receiving an entity , invokes* PSKExt* to obtain the entity partial secret key and returns it to . : receiving an entity , invokes* SetUkey* to obtain the entity secret key and returns it to . Here, returns if the entity has already appeared in . : receiving an entity and a message , invokes* SetUkey* to obtain and then performs* Sign* to generate the signature for under . At last, returns it to .(iii)* Forgery*: returns and wins if the following conditions hold:(1) is a valid signature of on .(2) is not requested in and .(3) is not an output in .

*Game 2 (for HKGC attacker)*(i)*Setup*: given a security parameter , invokes* Setup* to produce the master secret key and system parameters . Both and are given to .(ii)*Queries*: here, may request any oracles defined in* Game 1*, except for and , in an adaptive manner. Note that it is unreasonable to ask to respond to the signing queries if has been replaced.(iii)*Forgery*: outputs and wins if the following conditions hold:(1) is a valid signature of on .(2) is not requested in and .(3) is not an output in .

Au et al. illustrated the definition about malicious-but-passive KGC (MKGC) attacker, which is a stronger and more realistic security requirement. This MKGC may embed extra trapdoors in their system parameters before running* PSKExt*. To capture MKGC attacks, the following* Setup* algorithm is adopted in* Game 2*.(i)*Setup*: invokes to initialize the system public/secret parameters (). Here, to mount an attack more easily, is allowed to set some trapdoors during the initialization phase.

*Definition 1. *If none of the adversaries can win the above two games with a nonnegligible advantage, in a probabilistic polynomial time (PPT), the signature scheme in certificateless settings is strongly unforgeable against adaptive chosen message attacks.

#### 3. Analysis of HT Scheme

##### 3.1. Review on HT Scheme

Here, we restate HT scheme [21] by the following five algorithms:(i)*Setup*: given an instance (), KGC firstly picks at random and computes and then sets the master secret key , where . Furthermore, KGC randomly chooses , and sets four vectors , , , and , respectively. Next, KGC selects five classical collision-resistant hash functions , , , and , where , , and are fixed lengths. Finally, KGC publishes , ).(ii)*PSKExt*: let be a bit string from hashing an entity . Next, KGC randomly picks from and computes , where . Finally, KGC secretly transmits to the entity.(iii)*SetUkey*: given an entity , this algorithm firstly chooses two random secret values , generates the entity public key , and then computes and , where and are two bit strings of length . Finally, the entity secret value is set to , where and . Here, .(iv)*Sign*: given a message , an entity public key , and an entity secret key , this algorithm randomly selects , and computes and . Then, the signature is set by computing , where .(v)*Verify*: given on under with , this algorithm can verify ’s validity by the following equation: where , , , , and .

##### 3.2. Attacks on HT Scheme

###### 3.2.1. Strong Forgery Attack

Here, we indicate that an attacker generates a new forgery from an existing signature on by interacting with the challenger .

*Stage 1. * normally invokes the* Setup* algorithm to produce and , . Here, sends to and keeps by itself.

*Stage 2. *Given a target entity and a message , first invokes the* PSKExt* and* SetUkey* algorithms to generate the entity secret key and then invokes the* Sign* algorithm to obtain a signature of on . Obviously, the signature concrete forms are , where .

*Stage 3. *In order to generate for under , randomly picks and sets , , and .

It is clear that is a new valid signature for on with since

*Remark 2. *We notice that there is a flaw in Hung et al.’s security proof. More specifically, when receiving a signing query on , first picks at random and then sets the hash value to successfully compute the simulated signature . According to Hung et al.’s simulation process, we know that , where , , or . Obviously, the verification equation is always not true since , where . That is to say, cannot always give a valid response to a signing query required by an attacker with nonnegligible probability.

###### 3.2.2. MKGC Attack

Here, we will show that the HT scheme cannot capture MKGC attacks by an interaction between and as follows.

*Stage 1. *Here, is responsible for initializing the system parameters and sends them to . In particular, adaptively sets the parameters , where .

*Stage 2. *In the queries phase, can obtain the target entity public key . Next, derives the corresponding secret value by computing , , and , where and .

*Stage 3. *Now, can recover the entity full secret key and sign any message instead of the targeted entity.

*Remark 3. *In MKGC attacks, the KGC can adaptively set some trapdoor in the system parameters during the setup phase which may enhance its attack success probability. Obviously, in the security proof [21], the attacker passively received the master secret key and public parameters generated by the challenger like all the previous schemes [15–23], which did not consider how to capture the MKGC attacks.

#### 4. Our CLS Scheme

In this section, we construct an improved strongly unforgeable certificateless signature scheme and demonstrate its security on the condition that both [3, 24] are secure, and DL and CRHF assumptions hold.

##### 4.1. Building Blocks

*Paterson and Schuldt’s Identity-Based Signature Scheme (PIBS) [3]*(i)*Setup*: let () be an instance described in Section 2. First, pick a random element from and compute . Then, choose random elements from and two vectors , of lengths and , respectively, whose entries are random elements from . Finally, the master secret key is and the system parameter is .(ii)*Extract*: let , where is an entity. Set . To construct ’s secret key , pick a random number from and compute (iii)*Sign*: let be the set of indices such that , where is the th bit of message . is constructed by picking a random element from and computing (iv)*Verify*: given a signature of under , a verifier accepts if the following equality holds: Output 1 if it is valid. Otherwise, output 0.

*Boneh et al.’s Signature Scheme (BSW) [24]*(i)*SetUKey*: let () be an instance described in Section 2. First, pick a random number from and set . Then, choose three random values from where is known and a random -length vector whose elements are also chosen from . In addition, choose two random collision-resistant hash functions and . Finally, output the secret key and the public key .(ii)*Sign*: given a message , first, pick two random numbers , from and compute , where . Then, set . At last, is constructed by computing (iii)*Verify*: given of under , first, compute , where . Then, set . Finally, verify the following equation:

##### 4.2. Our Concrete Scheme

Let () be an instance described in Section 2. In our scheme, three classic hash functions, , , and , are adopted from to handle arbitrary messages and identities. Note that the cyclic groups and hash functions are publicly confirmed by all interested parties.(i)*Setup*: first, choose random elements from . Then, compute . Finally, the master secret key is and system parameter is .(ii)*PSKExt*: let where is an entity. Set . To construct ’s partial secret key , pick a random number from and compute (iii)*SetUKey*: first, choose random elements from . Then, compute . At last, let the public key be and the secret values be . Note that .(iv)*Sign*: given , , and , the signer selects two random numbers , computes , and sets , where , , where , and , where , respectively. At last, is constructed by computing (v)*Verify*: given of under , any verifier first computes , and , where . Then, the verifier sets , , and , respectively. Finally, the equalities are checked as follows: Output 1 if the equations hold. Otherwise, output 0.

For simplicity, we may set and because the others called implicit master secret keys/secret values are not used during its execution. Here, they are explicitly listed to easily prove its security as follows.

##### 4.3. Security Analysis

In this subsection, we introduce two lemmas to demonstrate that our scheme is strongly unforgeable against PKR attacks and MKGC attacks based on the CDH, DL and CRHF assumptions defined in Section 2.

Lemma 4. *Our scheme is strongly secure against PKR attacks launched by the attacker assuming PIBS is weakly secure [3], the discrete log problem is intractable in , and finding concrete collisions is difficult in .*

*Analysis*. Given any PPT adversary trying to break our CLS scheme in an adaptive chosen-message attack, we can forge a PPT adversary producing a weak forgery on the* PIBS* scheme/solving discrete log in /finding concrete collision of . Moreover, to consistently answer ’s queries, keeps a table which is initially empty in our security proofs.

*Init*. First, if attempt to break the* PIBS* scheme, randomly picks a number from and sets , else directly picks a random value from . Then, chooses three hash functions , , and from a classic hash family . Finally, returns (PIBS.) to as the system parameters . Here, in order to make the initialization appropriate, we flip a coin to predict the forgery type launched by .

*Queries*. In the query phase, responds to ’s all queries defined in their security model as follows:

: runs* PIBS.Extract* on to obtain the partial secret key and returns it to .

: searches to find the entity and get the entity secret value . If it does not exist, first picks random values from and stores them in . Finally, returns to as the secret key for .

: searches to discover the entity and returns to . Otherwise, first picks random values from and then stores those values in . At last, is returned to as the entity public key.

: searches to find the entity and update its public key using a new public key . If it does not exist, directly sets the entity public key to be .

: for a signature of a message on the entity public key ,(i)if attempts to break* PIBS* by means of ’s ability, picks a random value from and runs* PIBS.Sign* to produce . Moreover, computes to recover .(ii)Otherwise, invokes* PPKExt* to generate ’s partial secret key . Then, picks two random values from and simulates* PIBS.Sign* to produce where .

Next, computes and sets where . At last, sets and returns it to .

*Forgery*. If outputs on for with such that(i), can succeed in breaking the* PIBS* scheme by forging a valid signature on the message ;(ii) but , can succeed in finding a concrete collision to hash function ;(iii) but , can succeed in solving the discrete logarithm problem by computing ;(iv), but , can succeed in finding a concrete collision to hash function .

Here, , , and denote those elements queried/involved during the query phase.

Lemma 5. *Our scheme is strongly secure against MKGC attacks launched by assuming BSW is strongly existential unforgeable.*

*Analysis*. Given a PPT adversary breaking our CLS scheme in an adaptive chosen-message attack, we simulate a PPT adversary producing a strong forgery on the* BSW* scheme. Moreover, to consistently answer ’s queries, keeps a table which is initially empty in our security proofs.

*Init*. invokes to initialize the master secret key and the system parameters . Here, in order to launch MKGC attacks more easily, is allowed to set some trapdoors during the initialization phase.

*Queries*. In the query phase, responds to ’s all queries involved in their security model as follows:

: searches to find the entity and get the entity secret value . If it does not exist, first picks random values from and stores them in . Finally, returns to as the secret key for .

: Analogously, looks up to find the entity and returns to . If is not found, first picks random elements from and then stores those values in . At last, sets and returns these elements to .

: searches to find the entity and updates the entity public key using a new public key . If it does not exist, directly sets the entity public key to be provided by .

: for a signature query on a message under an entity with the public key , first invokes* PPKExt* to get the entity partial secret key and then runs* BSW.Sign* to generate . Next, computes and sets , where and . At last, sets and returns it to .

*Forgery*. If eventually returns for under with , can succeed in breaking the* BSW* scheme by forging a valid signature on the message where . Note that and are two types of classic hash in the* BSW* scheme.

In general, we demonstrate that our CLS scheme is strongly unforgeable against PKR attacks and MKGC attacks in the standard model by combining Lemmas 4 and 5.

##### 4.4. Discussion

Although our scheme has more parameters compared with the existing schemes, it not only overcomes the weakness of those previous schemes but also is proven to be secure under our stronger security model. In Lemma 5, the KGC can set some trapdoors in the system parameters adaptively rather than passively receiving the master secret key and the corresponding public parameters from the challenger like in the previous schemes, which is consistent with the actual situation in a concrete scheme. To the best of our knowledge, we are the first to prove a CLS scheme to be strongly secure against the MKGC attacks without random oracles.

#### 5. Conclusion

In this paper, we firstly showed that Hung et al.’s scheme cannot meet the requirements of strong unforgeability as they claimed. Then, we pointed out that their construction does not withstand the MKGC attacks and gave a concrete forgery to break it. Finally, we constructed an improved strongly unforgeable certificateless signature scheme and proved its security under the MKGC attacks in the standard model.

#### Conflicts of Interest

The authors declare that they have no conflicts of interest.

#### Acknowledgments

This work was supported by National Science Foundation of China (Grants nos. 61373158, 61472165, 61732021, and 61702222), Guangdong Provincial Engineering Technology Research Center on Network Security Detection and Defence (Grant no. 2014B090904067), Guangdong Provincial Special Funds for Applied Technology Research and Development and Transformation of Important Scientific and Technological Achieve (Grant no. 2016B010124009), Guangzhou Key Laboratory of Data Security and Privacy Preserving, and Guangdong Key Laboratory of Data Security and Privacy Preserving.