Mathematical Problems in Engineering

Volume 2014 (2014), Article ID 728591, 16 pages

http://dx.doi.org/10.1155/2014/728591

## Secure Certificateless Signature with Revocation in the Standard Model

Department of Mathematics, National Changhua University of Education, Chang-Hua City 500, Taiwan

Received 6 May 2014; Revised 3 September 2014; Accepted 3 October 2014; Published 19 November 2014

Academic Editor: Kwok-Wo Wong

Copyright © 2014 Tung-Tso Tsai et al. This is an open access article distributed under the Creative Commons Attribution License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.

#### Abstract

Certificateless public key cryptography is very attractive in solving the key escrow problem which is inherent in identity- (ID-) based public key cryptography. In the past, a large number of certificateless cryptographic schemes and protocols were presented, but a secure certificateless signature in the standard model (without random oracles) is still not accessible until now. To the best of our knowledge, all the previously proposed certificateless signature schemes were insecure under a considerably strong security model in the sense that they suffered from outsiders’ key replacement attacks or the attacks from the key generation center (KGC). In this paper, we propose a certificateless signature scheme without random oracles. Moreover, our scheme is secure under the strong security model and provides a public revocation mechanism, called revocable certificateless signature (RCLS). Under the standard computational Diffie-Hellman assumption, we formally demonstrate that our scheme possesses existential unforgeability against adaptive chosen-message attacks.

#### 1. Introduction

In 2001, Boneh and Franklin [1], led by Shamir’s idea [2], realized a practical construction of an identity- (ID-) based public key system (ID-PKS) by using bilinear pairings, such as Weil, Tate, and Ate pairings. Subsequently, the study of ID-based cryptographic mechanisms using bilinear pairings has received a great attention from researchers. A large number of literatures, such as [3–7], have been presented. An ID-based public key system consists of two roles, namely, a trusted private key generator (PKG) and users. A user’s identity information, such as social security number, e-mail address, and IP address, is viewed as her/his public key and the corresponding private key is computed and issued secretly by the trusted PKG. Evidently, the PKG owns all the users’ private keys so that it can decrypt ciphertexts or sign messages on behalf of any user as it wishes. Hence, an ID-based public key system always inherits an imperfection—the key escrow problem.

To overcome the key escrow problem in ID-based public key systems, Gentry [8] introduced the concept of certificate-based public key system, which contains two roles, namely, a key generation center (KGC) and users. Here, we roughly describe Gentry’s system. A user first generates the public key and then sends it to the KGC. The KGC generates a certificate for the user’s public key and then sends it to the user. The certificate also acts as a decryption or signing key of the user.

In 2003, Al-Riyami and Paterson [9] proposed a new paradigm for public key cryptography by combining the traditional public key system (PKS) with ID-PKS, termed certificateless public key system. As a result, certificates are no longer needed, but the two roles, namely, a KGC and users, remain in their certificateless public key system. A user’s private key consists of two components: a partial private key and a secret key. They are generated by the KGC and the user, independently. In this case, the KGC does not have access to the user’s full private key due to the lack of the secret key generated by the user. Hence, this certificateless design resolves the key escrow problem in ID-based public key systems. Subsequently, a numer of certificateless cryptographic schemes and protocols have been studied [10–22].

Al-Riyami and Paterson [9] presented a security model for certificateless public key cryptography. It consists of two types of adversaries, namely, outsiders (Type I adversary) and the KGC (Type II adversary). They also presented a concrete certificateless signature (CLS) scheme but did not offer security notion for this kind of scheme. Two years later, Huang et al. [11] first provided formal security notion for CLS schemes and pointed out that Al-Riyami and Paterson’s scheme above suffers from key replacement attacks from outsiders in the sense that, by replacing a user’s public key, an outsider can forge valid signatures without the knowledge of the user’s partial private key. In 2004, Yum and Lee [23] gave a generic construction of CLS schemes by combining an ID-based signature scheme with a signature scheme based on traditional public key systems. In 2006, Hu et al. [12] presented a considerably strong security model for CLS schemes and pointed out a security drawback in Yum and Lee’s construction. Since then, Hu et al.’s security model is considered promising and is generally adopted to formalize the security of CLS schemes.

To improve the efficiency of CLS schemes, several constructions of CLS were built and discussed such as [24–27]. In addition, for providing relatively short signature, Huang et al. [14] proposed a certificateless short signature scheme, which was shown to suffer from key replacement attacks by Shim [28]. Recently, Chen et al. [29] wrote a survey article on CLS schemes, in which they also presented a secure certificateless short signature scheme.

The security of all the CLS schemes mentioned above was based on the random oracle model [30]. Although these schemes offer better performance, they could be insecure when random oracles are instantiated with some particular hash functions such as SHA-1. In order to compensate this situation, a secure CLS scheme in the standard model (without random oracles) must be constructed. Based on the ID-based signature scheme presented by Paterson and Schuldt [31], Liu et al. [16] proposed the first CLS scheme in the standard model. However, Xiong et al. [17] pointed out that Liu et al.’s scheme is insecure against KGC attacks. To withstand the KGC attacks, two CLS schemes [18, 21] were independently proposed but later shown to be insecure [32, 33]. To our best knowledge, a secure CLS in the standard model (without random oracles) is still not accessible. All the previously proposed CLS schemes in the standard model were insecure under Hu et al.’s strong security model in [12] in the sense that they suffered from key replacement attacks from outsiders (Type I adversary) or attacks from the key generation center (Type II adversary).

A public key system should provide an efficient revocation mechanism to revoke misbehaving/compromised users. In traditional public key systems, users are able to know the revoked public keys by querying the certificate revocation list (CRL) [34] which contains all the revoked public keys. Evidently, the CRL approach is no longer suited for the certificateless public key system due to the lack of the usage of certificates. So, revoking misbehaving/compromised users in certificateless public key system has received attention from cryptographic researchers. Recently, Tsai and Tseng [22] and Shen et al. [35], independently, used the revocation technique presented by Tseng and Tsai [36] to propose a revocable certificateless public-key encryption (RCL-PKE) scheme. However, there was little work in constructing a revocable CLS scheme without random oracles.

*Our Construction*. In this paper, we will propose a CLS scheme with revocation in the standard model, called* revocable certificateless signature* (RCLS). This scheme includes two merits.(1)Under the standard computational Diffie-Hellman assumption, our scheme is secure under Hu et al.’s strong security model. We will formally demonstrate that our scheme possesses existential unforgeability against adaptive chosen-message attacks under the standard computational Diffie-Hellman assumption.(2)Our CLS scheme provides a public revocation mechanism to revoke misbehaving/compromised users.

The rest of the paper is organized as follows. We give some preliminaries in Section 2. In Section 3, we review the framework and security notion for RCLS schemes. A concrete RCLS scheme in the standard model is proposed in Section 4. We analyze the security of the proposed scheme in Section 5. In Section 6, we present discussions and comparisons between some existing schemes and ours. Finally, a concluding remark is drawn in Section 7.

#### 2. Preliminaries

In this section, we will review some fundamentals required in this sequel, namely, the concept of bilinear pairings and the related assumption.

##### 2.1. Bilinear Pairings

In the sequel, and denote two multiplicative cyclic groups of large prime order . A map is called an admissible bilinear map if it satisfies the following properties.(1)The map is bilinear: given and , we have .(2)The map is nondegenerate: there exist such that .(3)The map is efficiently computable. We refer the reader to previous literature, such as [1, 9], for a more comprehensive description of groups, maps, and other parameters.

##### 2.2. Related Mathematical Assumption

Here, we introduce the computational Diffie-Hellman (CDH) problem and define its corresponding security assumption (CDH assumption) on which our scheme is based.

*Definition 1. *Let be a generator of . Given with unknown randomly chosen from , the CDH problem is to compute . The associated CDH assumption states that there exists no probabilistic polynomial-time adversary that can solve the CDH problem with nonnegligible probability. The successful probability (advantage) of the adversary is presented as
where the probability is over the random choice consumed by the adversary .

#### 3. Framework and Security Notion of Revocable Certificateless Signature

In this section, we will define the framework and security notion for our RCLS scheme. In 2003, Al-Riyami and Paterson [9] presented a concrete certificateless signature (CLS) scheme, but did not give formal security notion for such schemes. Later, Yum and Lee [23] and Huang et al. [11] defined formal security notion for CLS schemes. Furthermore, Hu et al. [12] enhanced the definitions in [11, 23] to permit stronger queries. Since then, Hu et al.’s security model is generally adopted to formalize the security of CLS schemes. By modifying Hu et al.’s framework and security notion for CLS schemes [12], we present a framework of our RCLS scheme by adding* time key update algorithm*. Under this new framework, a user’s partial private key consists of two components, namely, an initial secret key (fixed since being issued) and a time update key (altered every period of time). As a result, the issue on time update key queries must be addressed in the security notion for CLS schemes.

*Definition 2. *A revocable certificateless signature (RCLS) is specified by six algorithms, namely, the system setup, the initial key extract, the time key update, the user key generation, the signing, and the verification. (i)*System setup*: this algorithm takes security parameter and the total number of periods as input and returns a system secret key, a time secret key, and the public parameters . We assume that are publicly and authentically available in all the following algorithms.(ii)*Initial key extract*: this algorithm takes the system secret key and a user’s identity as input and returns the user’s initial secret key to the user via a secure channel.(iii)*Time key update*: this algorithm takes the time secret key, a user’s identity , and a period as input and returns the user’s time update key to the user via a public channel.(iv)*User key generation*: this algorithm takes the public parameters and as input and outputs the secret key and public key .(v)*Signing*: this algorithm takes a user’s initial secret key , the user’s time update key , the user’s secret key , and a message as input and returns a signature .(vi)*Verification*: taking a signature , a message , a user identity , a period , and the user’s public key as input; the algorithm outputs either “accept” or “reject.”

*Remark 3. *The* system setup*, the* initial key extract*, and the* time key update* algorithms are run by the KGC, while the* user key generation* algorithm is run by the user.

There are three types of adversaries in our security notion for RCLS schemes. In the following, we will employ a security game to model security notion for RCLS schemes. The security game describes the interaction between a challenger and an adversary. Before introducing the security game, we first describe capabilities of Type I, Type II, and Type III adversaries, respectively.(i)Type I adversary (outsider): an adversary of this type does not have access to the system secret key and time secret key, but she/he can replace the public key of any entity with another of her/his own choice.(ii)Type II adversary (KGC): an adversary of this type is the KGC who knows the system secret key and time secret key. The KGC can produce the initial secret key and time update key of arbitrary identity, but it is forbidden to replace the public key of any identity at any time.(iii)Type III adversary (revoked user): an adversary of this type used to be a member of the system before being revoked by the system. A revoked user still owns the initial secret key although the system stops issuing the current time update key for her/him.

*Definition 4. *A RCLS scheme is existential unforgeable against chosen message attack if there is no probabilistic polynomial-time (PPT) adversary which has non-negligible advantage in the following security game. (i)*Setup*. A challenger takes a security parameter and runs the* system setup* algorithm. The challenger gives the public parameters to the adversary . Meanwhile, if is of Type II adversary, gives the system secret key and time secret key to . Otherwise, the challenger keeps them for itself.(ii)Phase 1. The adversary may issue the* public key retrieve*,* public key replace*,* initial key extract*,* time key update*,* secret key extract*, and* signing queries* as follows.(a)*Public key retrieve query (**)*. When issues this query with an identity , the challenger returns the corresponding public key to .(b)*Public key replace query (**)*. In such a query, the adversary replaces the public key of the identity with . The challenger records the replacement.(c)*Initial key extract query (**)*. When issues this query with an identity , the challenger runs the* initial key extract* algorithm to return the initial secret key .(d)*Time key update query (**)*. When issues this query with an identity in a period , the challenger runs the* time key update* algorithm to return the time update key .(e)*Secret key extract query (**)*. When issues this query with an identity , the challenger returns the secret key . Here, the query is forbidden if the identity has already appeared in the* public key replace query*.(f)*Signing query (**)*. When issues this query with , the challenger uses the initial secret key , the time update key , and the secret key to run the* signing* algorithm to obtain a signature on the message . The challenger then returns to no matter whether the identity appears in the* public key replace query* or not. Note that a Type I adversary can issue all types of queries except the* initial key extract query* on ; a Type II adversary can issue all types of queries except the queries on public key replace and the* secret key extract query* on ; a Type III adversary (revoked user) is allowed to issue all types of queries except the* time update key query* on .(iii)*Forgery*. The adversary outputs . We say that the adversary wins this game if the following conditions are satisfied.(1)The response of the algorithm on is “accept.”(2) has never been submitted during the* signing query* process.

*Remark 5. *Since a Type II adversary owns the system secret key and the time secret key, it is able to generate any initial secret key and time update key. Hence, a Type II adversary does not need to issue the queries on initial secret key and time update key.

#### 4. Concrete Revocable Certificateless Signature Scheme

In this section, we describe a concrete revocable certificateless signature scheme that consists of six algorithms.(i)*System setup*: the KGC takes a security parameter as input and returns , where is an admissible bilinear map and and are two cyclic groups of sufficiently large prime order . Then, the KGC sets five collision-resistant hash functions , , , , and , where , , , , and are fixed. Furthermore, the KGC randomly chooses five values , , , , and five vectors , , , , , where , , , , for , , , , and . A generator of and two values are picked. The KGC computes and randomly chooses to set the system secret key as and the time secret key as . Then, the public parameters are presented as , .(ii)*Initial key extract*: given a user’s identity , the KGC computes a bit string . The KGC then chooses a random value and uses the system secret key to compute the user’s initial secret key . The KGC transmits to the user via a secure channel.(iii)*Time update key*: given a user’s identity and a period , the KGC computes a bit string . The KGC then chooses a random value and uses the time secret key to compute the user’s time update key . The KGC transmits to the user via a public channel.(iv)*User key generation*: given a user’s identity , this algorithm selects two secret values and computes the user’s public key . Then, the algorithm first computes two bit strings and . Finally, the algorithm uses the selected two secret values to compute the user’s secret key .(v)*Signing:* given a message , a signer computes a bit string . The signer chooses a random value and computes . The signer uses her/his initial secret key , time update key , and secret key to compute a signature on the message as follows:
(vi)*Verification*: given a period , a signature on a message for a signer with an identity and the signer’s public key , a verifier first computes five bit strings , , , , and . Finally, the verifier checks the following equation:

#### 5. Security Analysis

In this section, we establish three theorems to demonstrate that, under the CDH assumption, the proposed RCLS scheme offers existential unforgeability against adaptive chosen-message attacks for Type I, Type II, and Type III adversaries, respectively.

Theorem 6. *Under the CDH assumption, the proposed RCLS scheme is secure against Type I adversary (outsider). Concretely, if there is a Type I adversary that has an advantage against the proposed scheme within a running time , then we can construct an algorithm to solve the CDH problem with an advantage
**
within a running time + , in which , and are the numbers of queries on initial key extract, time key update, and signing, respectively, is the sum of the numbers of queries on public key replace and secret key extract, and and denote the executing time of a multiplication and an exponentiation in , respectively.*

*Proof. *Assume that a Type I adversary can forge a valid signature for the proposed RCLS scheme. We will construct an algorithm that solves the CDH problem as follows. Without loss of generality, we assume that there exists a tuple , as mentioned in Section 2, and the algorithm is given , where and are unknown to . In order to compute , the algorithm simulates a challenger in the following game. (i)*Setup*. A challenger (algorithm) first sets five collision-resistant hash functions , , , , and , where , , , , and are fixed. Note that the employed collision-resistant hash functions are not viewed as random oracles in our security proofs. The challenger then sets , , and and chooses three integers , , and at random, where , , and . We assume that , , and for the given values of , , , , and . The challenger randomly selects the integers , , , , , , and . Now, the challenger constructs a set of public parameters as follows. The challenger chooses a value as the time secret key. The challenger sets and . Furthermore, computes and a vector , where for ; and a vector , where for ; and a vector , where for ; and a vector , where for ; and a vector , where for . Now, the challenger has constructed a set of public parameters as , . Before performing and between the adversary and the challenger , we define seven functions , , , , , , and by
Here, as before, for an identity , for an identity in a period , and for a public key , and for a message . Finally, for the cumbersome notations defined above, we conclude with five relations to which will be referred frequently in the sequel; namely,
(ii)* Queries.* The challenger maintains a list of tuples of the form . Initially the list is empty. The adversary may make a number of queries in an adaptive manner as follows.(a)*Public key retrieve query (**)*: upon receiving a query for the public key of an identity , the challenger responds to the query as follows.(1)If appears in the list , the challenger responds with the corresponding .(2)If does not appear in the list , the challenger selects two secret values , sets the public key , and then computes , , and the secret key . The challenger adds the tuple in the list and returns as the query output. (b)*Public key replace query (**)*: upon receiving a query to replace the public key of an identity , the challenger accesses the tuple in the list . If appears in the list , the challenger replaces with . If does not appear in the list , the challenger adds the tuple in the list .(c)*Initial key extract query (**)*: upon receiving a query for the initial secret key of an identity , the challenger first sets , and then computes and . If , the challenger aborts. Otherwise, the challenger chooses a random value and responds with the initial secret key generated by
Here, is indeed a valid initial secret key since, by the first equality in (6),
where .(d)*Time key update query (**)*: upon receiving a query for the time update key of an identity in a period , the challenger first sets and then computes . The challenger chooses a random and uses the time secret key to compute the time update key as follows:
(e)*Secret key extract query (**)*: upon receiving a query for the secret key of an identity , the challenger accesses the tuple in the list . If appears in the list , the challenger responds with . If does not appear in the list , the challenger runs* user key generation* algorithm to add the tuple in the list and responds with .(f)*Signing query (**)*: consider a query for a message , an identity , a period , and a public key . The challenger first sets , , , , and . then computes , , , , , , and . If , the challenger reports failure and terminates. Otherwise, the challenger considers the following two cases. *Case 1*: assume that the identity has previously appeared in the* public key replace query*. If , the challenger can compute the initial secret key as in the* initial key extract query*. In addition, the challenger computes the time update key as in the* time key update query*. The challenger then chooses a random value and responds whit the signature
Note that is indeed a valid signature since and, by the equalities in (6),
where . On the other hand, if , the challenger first computes the time update key as in the* time key update query*. Then, the challenge chooses two random values and responds with the signature
Note that is also a valid signature since, by (6),
where . *Case 2*: assume that the identity has not previously appeared in the* public key replace query*. The challenger computes the time update key as in the* time key update query*. If , the challenger can compute the initial secret key as in the* initial key extract query* and accesses the list to obtain the corresponding secret key . The challenger chooses a random value and then responds with the signature
If , then chooses two random values and responds with the signature
(iii)*Forgery.* Assume that the adversary generates a valid signature for on in , where , , and are the target identity, period, and message, respectively. The challenger first accesses to the list to obtain . The challenger then computes , , , , , , , , , , , and . If , , or , the challenger aborts. Otherwise, that is, when , the challenger , by using (6), computes as follows:
Thus, the challenger resolves the computational Diffie-Hellman (CDH) problem.

Next, we proceed to the probability analysis for the simulation above. Note that if the simulation aborts, then the CDH problem will be unable to be computed by the challenger. In* Forge* phase, the adversary can generate a signature if the challenger can correctly response the adversary’s queries in Phase 1 and do not abort in the security game. If the signature is valid, the challenger can use it to solve the CDH problem. Thus, the probability of the challenger not aborting in the security game is equal to the probability of solving the CDH problem. Hence, we list the events that the challenger does not abort during the simulation process. (1)In the phase of* initial key extract query*: if , the challenger can correctly answer queries without aborting.(2)In the phase of* signing query*: if , the challenger can correctly respond queries without aborting.(3)In the phase of* forgery*: if , the challenger can perform the simulation without aborting.

Let be the number of identities appearing in either* initial key extract queries* or* signing queries* not involving the challenge identity. In addition, let be the number of identities with the period appearing in the* time key update queries* and let be the number of messages in the* signing queries* involving the challenge identity. Clearly, we will have , and . To simplify the analysis, we define the events mod for the query , mod , mod for the query , mod , and mod . From the above analysis, the probability of the challenger not aborting is

Note that, if mod , there will be a unique choice of with such that . Since are chosen randomly, we obtain that
By similar arguments, we have
We also have that
and, similarly,
Hence, we can obtain that
We have set , , and in the setup at the beginning of the proof, and so the resulting probability of the challenger not aborting is

Since the adversary that has an advantage against the proposed certificateless signature scheme, the challenger has an advantage
to solve the CDH problem.

For the queries, we observe that there are multiplications and exponentiations in the* initial key extract queries*. There are multiplications and exponentiations in the* time update key queries*. There are multiplications and exponentiations in both the* public key retrieve* and the* secret key extract queries*. Moreover, there are multiplications and O(1) exponentiations in the* signing queries*. So we have + , where and denote the executing time of a multiplication in and an exponentiation in , respectively.

Theorem 7. *Under the CDH assumption, the proposed RCLS scheme is secure against Type II adversary. Concretely, if there is a Type II adversary (KGC) that has an advantage against the proposed scheme within a running time , then we can construct an algorithm to solve the CDH problem with an advantage
**
within a running time + , in which and are the numbers of queries on secret key extract and signing, respectively, and and denote the executing time of a multiplication and an exponentiation in , respectively.*

*Proof. *We assume that a Type II adversary can forge a valid signature for the proposed RCLS scheme. We will construct an algorithm that solves the CDH problem as follows. Without loss of generality, we assume that there exists a tuple , as mentioned in Section 2, and the algorithm is given , where and are unknown to . In order to compute , the algorithm simulates a challenger in the following game. (i)*Setup*. A challenger (algorithm) first sets five collision-resistant hash functions , , , , and , where , , , , and are fixed. Note that the employed collision-resistant hash functions are not viewed as random oracles in our security proofs. The challenger then sets and chooses an integer at random, where . We assume that for the given values of and . The challenger randomly selects the integers: , , , , , and . Now, the challenger constructs a set of public parameters as follows. The challenger chooses two values . The challenger sets and . Furthermore, computes and sends the system secret key and time secret key to the adversary . Also, computes and a vector , where for ; and a vector , where for ; and a vector , where for ; and a vector , where for ; and a vector , where for . Now, the challenger has constructed a set of public parameters as , . Before performing and between the adversary and the challenger , we define six functions , , , , , and by
Here, as before, for an identity , for an identity in a period , and for a public key , and for a message . Finally, for the cumbersome notations defined above, we conclude with four relations to which will be referred frequently in the sequel; namely,
(ii)*Queries.* The challenger maintains a list of tuples of the form . Initially the list is empty. First, without loss of generality, the challenger picks a target identity , selects a secret value , and sets the public key . Then, the challenger adds the tuple in the list . The adversary may make a number of queries in an adaptive manner as follows.(a)*Public key retrieve query (**)*: upon receiving a query for the public key of an identity , the challenger responds to the query as follows.(1)If appears in the list , the challenger responds with the corresponding .(2)If does not appear in the list , the challenger selects two secret values , sets the public key , and then computes , and the secret key . The challenger adds the tuple in the list and returns as the query output. (b)*Secret key extract query (**)*: consider such a query along with an identity . If , the challenger aborts. If and appears in the list , the challenger accesses the tuple in the list and responds with . If and does not appear in the list , the challenger runs the* user key generation* algorithm to add the tuple in the list and then responds with so obtained.(c)*Signing query (**)*: consider a query for a message , an identity , a period , and a public key . The challenger first sets , , , , and . then computes , , , , , and . If , the challenger reports failure and terminates. Otherwise, the challenger considers the following two cases. *Case 1*: if , the challenger runs the* initial key extract* and* time key update* algorithms to obtain the initial secret key and the time update key . The challenger chooses a random value and then responds with the signature
Note that is indeed a valid signature since and, by the equalities in (27),
where . *Case 2*: if , the challenger runs the* initial key extract* and* time key update* algorithms to obtain the initial secret key and the time update key . Then, accesses to the list to obtain the secret key . The challenger chooses a random value and then responds with the signature
(iii)*Forgery.* Assume that the adversary generates a valid signature for on in , where , , and are the target identity, period, and message, respectively. If , the challenger reports failure and terminates. If , the challenger first accesses to the list to obtain . The challenger then computes , , , , , , , , , , and . If , the challenger aborts. Otherwise, that is, when , the challenger , by using (27), computes as follows: