Certificate-based signatures revisited

Certificate-based encryption was introduced in Eurocrypt'03 to solve the certificate management problem in public key encryption. Recently, this idea was extended to certificate-based signatures. Several new schemes and security models of certificate-based signatures have been proposed. In this paper, we first take a closer look at the certificate-based signature by comparing it with digital signatures in other popular public key systems. We introduce a new security model of certificate-based signature, which defines several new types of adversaries against certificate-based signatures, along with the security model of certificate-based signatures against them. The new model is clearer and more elaborated compared with other existing ones. We then investigate the relationship between certificate-based signatures and certificateless signatures, and propose a generic construction of certificate-based signatures. We prove that the generic construction is secure (in the random oracle model) against all types of adversaries defined in this paper, assuming the underlying certificateless signatures satisfying certain security notions. Based on our generic construction, we are able to construct new certificate-based signature schemes, which are more efficient in comparison with other schemes with similar security levels.


Introduction
In a public-key cryptosystem, each user has a pair of keys: public key and private key. The public key is always published and publicly accessible, while the private key is kept secret by the owner. The central problem in a public key system is to prove that a public key is genuine and authentic, and has not been tampered with or replaced by a malicious third party. The usual approach to ensure the authenticity of a public key is to use a certificate. A (digital) certificate is a signature of a trusted certificate authority (CA) that binds together the identity of an entity A, its public key P K and other information. This kind of systems is referred as public key infrastructure (PKI). The PKI is generally considered to be costly to use and manage. by transmitting it along with messages (for example, in a signing application) or by placing it in a public directory (this would be more appropriate for an encryption setting). However, there is no certificate to ensure the authenticity of the entity's public key in CL-PKC. Therefore, it is necessary to assume that an adversary is able to replace the entity's public key with a false key of its choice, which is also known as key replacement attack [Huang et al. 2005]. One assumption in CL-PKC is that KGC never mounts the key replacement attack. In the traditional PKI, however, one does not need to make the same assumption on the third party CA, who if replaces the entity's public key with a false key of its choice, can be implicitly proved due to the existence of the certificate for that false key.
In Eurocrypt 2003, Gentry [Gentry 2003] introduced the notion of certificatebased encryption. As in the traditional PKI, each client generates its own public/private key pair and requests a certificate from the CA. The difference is that, a certificate in the certificate-based cryptography, or more generally, a signature from the third party acts not only as a certificate (as in the traditional PKI) but also as a decryption key (as in ID-PKC and CL-PKC). The sender can encrypt a message without obtaining explicit information other than the recipient's public key and the parameters of CA. To decrypt a message, a keyholder needs both its secret key and an up-to-date certificate from its CA (or a signature from an authority). Therefore, CA does not need to make the certificate status information available among the whole system, and only needs to contact the certificate holder for revocation and update. As the sender is not required to verify the certificate of the recipient's public key, the sender could be duped to encrypt messages with an uncertified public key. This could be due to the recipient has not yet had his/her public key certified, or the encryption key that the sender holds is not the recipient's authentic public key. In this sense, certificate-based encryption works in a similar way to certificateless encryption, but the difference is that certificates do exist in certificate-based encryption.
Certificate-based cryptography was introduced to solve the certificate management problem in the traditional PKI, but only in the scenario of encryption. The notion of certificate-based encryption was extended to certificatebased signature in [Kang et al. 2004, Li et al. 2007]. However, as mentioned in [Gentry 2003], if we only consider signing and verification signatures in a public key cryptosystem, then the certificate management problem is not as challenging as in the scenario of encryption and decryption. For example, the signer can send its public key and the proof of certificate status to the verifier simultaneously with its signature, thus the verifier can obtain the certificate without referring to a public directory or issuing a third-party query to CA. This, however, will require more bandwidth for signature transmitting. Public key cryptosystems like ID-PKC [Shamir 1985, Boneh andFranklin 2001] and CL-PKC [Al-Riyami and Paterson 2003] can eliminate the certificate management problem as one can directly use the entity A's public key to verify signatures, without checking the certificate of A's public key. However, this is achieved at the cost of assuming certain trust on the authority, who is able to impersonate any user in an undetectable way. In certificate-based cryptosystem, certificate management problem can be eased in a different way. To generate valid certificatebased signatures of a user with the identity information ID and the public key P K, one needs two pieces of secret information, namely a valid certificate of (ID, P K) and the secret key of P K. In other words, a valid certificate-based signature ensures the existence of a valid certificate. Thus, the signer does not need to send the certificate along with the message and the signature. This is achieved at the cost of more computational operations in signature verification, which implies the verification of the certificate. If one replaces P K with P K' and generates a valid signature under ID and P K', he/she must have a certificate of (ID, P K ). This can prove that the third party CA is dishonest, as there is only one party with the ability to generate certificates. Therefore, the third party in certificate-based signatures has the Trust Level 3 in the definition in [Girault 1991], which is similar as CA in the traditional PKI and a few constructions of identity-based signatures [Bellare et al. 2004, Galindo et al. 2006]. To summarize, (1) The authority in certificate-based signatures and traditional PKI-based signatures is at Trust Level 3 in the definition given in [Girault 1991], which is higher than the authority in the ID-PKC and the CL-PKC, and (2) To ease the problem of certificate management, certificate-based signatures consume (in general) less bandwidth in signature transmitting but might require more computational cost than traditional-PKI-based signatures.

Related Work
Kang, Park and Hahn proposed the notion and the first construction of certificatebased signatures in [Kang et al. 2004], by extending the idea of certificate-based encryption in [Gentry 2003]. That is, to generate a valid signature under the public key P K, the entity needs to know both the corresponding private key SK and the up-to-date certificate of P K. To verify a claimed signature, one only needs the signer's public key and the parameter of CA (particularly, no need to check the certificate of that public key). As the verifier is not required to check the certificate about a claimed public key, key replacement attacks also exist in certificate-based cryptography. Key replacement attacks in certificatebased signatures were first addressed in [Kang et al. 2004] and formally defined in [Li et al. 2007]. As introduced in [Li et al. 2007], adversaries in certificatebased signatures can be divided into two types: CB-A I and CB-A II . CB-A I can replace any entity's public key P K with a new public key P K chosen by itself, and is trying to forge a valid signature under P K whose certificate is not available to CB-A I . CB-A II has the knowledge of CA's master key and thus can generate the certificate for any user. CB-A II is trying to forge a valid signature under an entity's authentic public key P K (that is, P K is chosen by that entity), whose private key is not available to CB-A II . In addition to the security models, a certificate-based signature scheme secure against key replacement attacks was also proposed in [Li et al. 2007]. Very recently, Liu et al. proposed two new certificate-based signature schemes [Liu et al. 2008]. The first one does not require any pairing operation and the security of their second scheme can be proved without random oracles. Some variants of certificate-based signatures (e.g., certificate-based proxy signature [Kang et al. 2004] and certificate-based linkable ring signature [Au et al. 2007B]) have also been proposed.

Motivations and Contributions
As mentioned in [Al-Riyami and Paterson 2003], certificate-based cryptography and certificateless cryptography are quite similar and there could be a possible method to convert a certificateless cryptographical protocol to a certificate-based cryptographical protocol. In particular, there are four similarities in certificateless signatures and certificate-based signatures.
1. In both public key cryptosystems, signature signing requires two pieces of secret information. In CL-PKC, one needs a partial private key and a secret value of a public key to produce valid signatures under that public key. Similarly, in certificate-based cryptosystem, one needs the certificate and the private key of a public key to generate valid signatures under that public key.
2. The partial private key is generated by KGC in CL-PKC. The certificate is generated by Certifier in certificate-based cryptosystem.
3. The secret value corresponding to a public key is chosen by the user in CL-PKC. The private key is also chosen by the user in certificate-based cryptosystem.
4. In both public key cryptosystems, explicit verification of the authenticity of a public key is not required when one verifies the validity of signatures under that public key.
Motivated by those similarities, we believe that certificate-based signatures and certificateless signatures are closely related, and the investigation of the relationship between those two notions is worthwhile. The contributions of this paper are twofold.

New Security Models of Certificate-based Signatures
A reasonable and elaborated security model is necessary for constructing provably secure cryptographic protocols. For example, although the key replacement attack has been widely accepted in certificateless cryptography, there is no consensus on the precise meaning of that term in the early research of certificateless cryptography and several certificateless signature schemes have been broken [Al-Riyami and Paterson 2003, Gorantla and Saxena 2005, Hu et al. 2006, Huang et al. 2005, Park 2006, Yum and Lee 2004. Although some security models [Kang et al. 2004, Li et al. 2007] have been proposed so far, the security definition of certificate-based signatures is not satisfactory, especially in the exact meaning of key replacement attacks. In this paper, we provide elaborated definitions of certificate-based signatures, which will allow us to establish a systematic approach for constructing and proving secure certificate-based signature schemes. Our definitions are inspired by and modified from the security notions in certificateless signatures. This is not only because certificateless signatures and certificate-based signatures are analogous in many ways, but also due to the fact that security definitions of certificateless signatures have been formalized recently.

Generic Construction of Certificate-based Signatures from Certificateless Signatures
After giving new security models of certificate-based signatures, we propose a generic construction of certificate-based signatures which is secure in the proposed models. We show how to build a certificate-based signature scheme from a certificateless signature scheme, by treating partial private keys in certificateless signatures as certificates in certificate-based signatures. Our method can be used to build certificate-based signature schemes secure (in the random oracle model) against any type of adversaries defined in this paper, assuming that the underlying certificateless signature schemes satisfy certain security notions. We also give two concrete examples of our generic construction and compare them with other existing ones. From essentially the same idea, the generic construction of certificate-based encryption from certificateless encryption has been proposed in [Al-Riyami and Paterson 2005], but a recent work in [Kang and Park 2005] shows a flaw in the security proof of [Al-Riyami and Paterson 2005]. Our construction does not have that flaw as we use different techniques in the conversion.

Organization of Our Paper
The outline of a certificate-based signature (CBS) scheme is presented in the next section, where the description of the oracles are also given. We then redefine the security of CBS against different types of attacks in Section 3. The generic construction of certificate-based signatures from certificateless signatures is proposed in Section 4. Section 5 demonstrates the application of our generic construction by showing two concrete certificate-based signature schemes. Fi-nally, Section 6 concludes the paper.

Certificate-Based Signatures
In this section, we will first review the definitions of certificate-based signatures. Then, we will describe oracles used in our security model.

Syntax of Certificate-Based Signatures
In a certificate-based cryptosystem, a certificate generator, which is called as the "certifier", will first generate the system parameter and a master public/private key pair. The certifier will use that key pair to generate certificates for users in the system. Users then will generate their own public/secret key pairs and contact the certifier to obtain the corresponding certificates. A user can use the secret key and the certificate to generate a signature on a message. In this case, that user is also called as the signer. A signature recipient is called as the verifier if he/she performs the signature verification. A certificate-based signature (CBS) scheme consists of the following five algorithms: 1. CB-Setup(1 k ) → (CB-msk, CB-mpk, CB-params). By taking as input a security parameter 1 k , the certifier runs the algorithm CB-Setup to generate the certifier's master secret key CB-msk, master public key CB-mpk and the system parameter CB-params. CB-params includes the description of a string space Γ , which can be any subset of {0, 1} * .
2. CB-UserKeyGen(CB-mpk, CB-params, ID) → (CB-SK ID , CB-P K ID ). The user with the identity information ID runs the algorithm CB-UserKeyGen to generate the user ID's secret/public key pair (CB-SK ID , CB-P K ID ) ∈ SK CB × PK CB , by taking as input CB-mpk and CB-params. Here, SK CB denotes the set of valid secret key values and PK CB denotes the set of valid public key values.
3. CB-CertGen(CB-msk, CB-mpk, CB-params, ID, CB-P K ID ) → Cert ID . The certifier runs the algorithm CB-CertGen to generate the certificate Cert ID , by taking as input CB-msk, CB-mpk, CB-params, ID and its public key CB-P K ID .
4. CB-Sign(m, CB-params, CB-mpk, ID, Cert ID , CB-SK ID , CB-P K ID ) → CBσ. The prospective signer runs the algorithm CB-Sign to generate the signature CB-σ, by taking as input a message m, CB-params, CB-mpk, the user's identity ID, its Cert ID and key pair (CB-SK ID , CB-P K ID ).
5. CB-Verify(m, CB-σ, CB-mpk, CB-params, ID, CB-P K ID ) → {true, f alse}. Anyone can run the algorithm CB-Verify to check the validity of the signature. By taking as input a message/signature pair (m, CB-σ), ID, CB-P K ID , CBmpk, CB-params, this algorithm outputs true if CB-σ is ID's valid signature on m. Otherwise, this algorithm outputs f alse.

Correctness.
Signatures generated by the algorithm CB-Sign can pass through the verification in CB-Verify. That is, CB-Verify(m, CB-Sign(m, CB-params, CB-mpk, ID, Cert ID , CB-SK ID , CB-P K ID ), CB-mpk, CB-params, ID, CB-P K ID ) = true.

Adversaries and Oracles
We now describe the oracles which will be used in the security model of certificatebased signatures in this paper. We first give a brief description of adversaries in certificate-based signatures. Formal definitions of these adversaries will be given in Section 3. The essential security of a certificate-based signature scheme requires that one can generate a valid signature under the public key CB-P K ID if and only if having the knowledge of both Cert ID and CB-SK ID . In other words, one cannot generate a valid signature with only Cert ID or CB-SK ID . As introduced in [Li et al. 2007], adversaries in certificate-based signatures can be divided into two types: CB-A I and CB-A II . Type I adversary CB-A I simulates the scenario where the adversary (anyone except the certifier) is allowed to replace public keys of any entities, but is not allowed to obtain the target user's certificate Cert ID . Type II adversary CB-A II simulates a malicious certifier who is able to produce certificates but is assumed not to replace the target user's public key. We will use the following oracles to simulate potential attacking scenarios. In the remainder of this paper, we write α ← β to denote the algorithmic action of assigning the value β to α.
1. O CB−UserCreate : This oracle receives an input ID ∈ Γ and outputs the public key of user ID. It maintains two lists L1 P K and L2 P K , which are initially empty and are used to record the information for each user ID. L1 P K ={(ID, CB-SK ID , CB-P K ID )} provides the information about user ID's secret key and public key when it is created. L2 P K ={(ID, CB-P K ID )} provides the information of ID's current public key, which is denoted as CB-P K ID .
(a) For a fresh input ID, the oracle runs the algorithms CB-UserKeyGen to obtain the secret key CB-SK ID and public key CB-P K ID . It then adds ID is said to be created. Here we assume that other oracles (which will be defined later) only respond to the identity which has been created.
(b) Otherwise, ID has already been created. The oracle will search ID in L1 P K and return CB-P K ID as the output.
2. O CB−PKReplace : For a public key replacement query (ID, CB-PK) ∈ Γ × PK CB , this oracle finds the user ID in the list L2 P K , sets CB-P K ID ← CB-PK and updates the corresponding pair with (ID, CB-P K ID ).
3. O CB−Corruption : This oracle takes as input a query ID. It browses the list L1 P K and outputs the secret key CB-SK ID .
4. O CB−CertGen : For a certificate request for (ID, CB-PK) ∈ Γ ×PK CB , this oracle runs the algorithm CB-CertGen and returns the certificate for (ID, CB-PK). Otherwise coin = 2, this oracle first checks the list L1 P K and L2 P K to obtain ID's original public key CB-P K ID and ID's current public key CB-P K ID . If CB-P K ID =CB-P K ID , this oracle works as same as O CB−NormalSign . Otherwise, O CB−StrongSign will ask the adversary to supply the secret key CB-SK ID corresponding to CB-P K ID . After that, this oracle uses CB-SK ID and the certificate for (ID,CB-P K ID ) to generate the signature CB-σ, which will be returned as the answer.

O
(c) O CB−SuperSign : For a query (ID, m), this oracle first finds ID's current public key CB-P K ID in L2 P K . This oracle then outputs a signature σ such that true = CB−Verify(m, σ, CB-params, ID, CB-P K ID , CBmpk).

Remark.
A Type II adversary CB-A II , who simulates the malicious certifier, is not allowed to make any requests to O CB−CertGen .

Security Models of Certificate-based Signatures
In this section, we will define security models of certificate-based signatures. Our models follow the standard methods: each security notion is defined by the game between the adversary and the challenger, which consists of several oracles defined in Section 2.2. In our definition, the notation The definition in this section is inspired by ], which provides a new classification of potential adversaries against certificateless signatures. The security models in ] not only include previous security definitions of certificateless signatures, but also introduce new types of adversaries. Following the definitions in ], we classify the potential adversaries in certificate-based signatures according to their attack power. They are Normal Adversary, Strong Adversary and Super Adversary. Combined with the known type I adversary and type II adversary in certificate-based signatures, we now define the security of certificate-based signatures in different attack scenarios and relate them to prior definitions.

Security Against Normal Type I Adversary
We first define the Normal Type I adversary in certificate-based signatures, which is denoted as Normal-CB-A I . The essential attacking scenario of Normal-CB-A I is that the adversary can obtain some message/signature pairs (m i , CB-σ i ) which are generated by the target user using its own secret key and certificate. Our definition described below is inspired by and modified from the definition of Normal Type I adversary against certificateless signatures in ].

Initial:
The challenger runs the algorithm CB-Setup, returns CB-params and CB-mpk to A I . Queries: In this phase, A I can adaptively make requests to O CB−UserCreate , Output: After all queries, A I outputs a forgery (m * , CB-σ * , ID * ). Let CB-P K ID * be the current public key of ID * in L2 P K . Restrictions: We say A I wins the game if the forgery satisfies the following requirements: The success probability that an adaptive chosen message and chosen identity adversary Normal-CB-A I wins the above game is denoted as Succ cma,cida AI ,normal . We say a certificate-based signature scheme is secure against a (t, q UC , q P KR , q C , q CG , Remark. Our definition is similar to that in [Li et al. 2007], but with two improvements. Firstly, we allow the adversary to replace any user's public key, while the adversary in [Li et al. 2007] can only replace the target user's public key. The other improvement is that the adversary in our model is allowed to obtain certificates of (ID, CB-P K)s chosen by itself. This is different from the adversary in [Li et al. 2007] who can only obtain certificates of original public keys generated by the challenger.

Security Against Strong Type I Adversary
In this section, we boost the attack power of Normal Type I adversary and define the Strong Type I adversary: Strong-CB-A I . Strong-CB-A I is more powerful than Normal-CB-A I in the sense that Strong-CB-A I can access the oracle O CB−StrongSign . Apart from that, Strong-CB-A I is allowed to corrupt the target user ID * 's original secret key. The attacking scenario is similar to those in certificateless signatures defined in [Hu et al. 2006, and is formally defined as below.
The game between the challenger and a Strong-CB-A I is very similar to that defined in Section 3.1, but with two differences: (1)  The success probability that an adaptive chosen message and chosen identity adversary Strong-CB-A I wins the above game is denoted as Succ cma,cida AI ,strong . We say a certificate-based signature scheme is secure against a (t, q UC , q P KR , q C , q CG , q S ) Strong-CB-A I if Succ cma,cida AI ,strong is negligible.

Security Against Super Type I Adversary
In this section, we will define the Super Type I adversary, which is denoted as Super-CB-A I . Super-CB-A I is more powerful than Strong-CB-A I (and hence, more powerful than Normal-CB-A I ) in the sense that Super-CB-A I has access to O CB−SuperSign . That is, Super-CB-A I is allowed to obtain a valid signature under the public key chosen by itself without providing the corresponding secret key, which makes it the strongest Type I adversary. This is similar to the Super Type I adversary in certificateless signatures defined in ].
The game between the challenger and a Super-CB-A I is very similar to that defined in Section 3.2, but with two differences: (1) In the phase Queries, Super-CB-A I is allowed to have access to O CB−SuperSign rather than O CB−StrongSign and (2) In Restrictions, (ID * , m * ) O CB−SuperSign . The success probability of an adaptively chosen message and chosen identity adversary Super-CB-A I wins the above game is denoted as Succ cma,cida AI ,super . We say a certificate-based signature scheme is secure against a (t, q UC , q P KR , q C , q CG , q S ) Super-CB-A I if Succ cma,cida AI ,super is negligible.

Security Against Type II Adversary
In certificate-based signatures, a type II adversary CB-A II simulates the certifier who is equipped with the master secret key and might engage in adversarial activities like eavesdropping on signatures and making signing queries. Similar to the type I adversary, CB-A II could be also classified into (1) true ← CB−Verify(m, CB-σ * , CB-params, ID * , CB-P K ID * , CB-mpk). Here CB-P K ID * is the original public key in L1 P K ; (2) (ID * , m * ) O CB−Sign ; and (3) ID * O CB−Corruption . The success probability that an adaptive chosen message and chosen identity adversary CB-A II wins the above game is denoted as Succ cma,cida AII ,type , where type ∈ {normal, super}. We say a certificate-based signature scheme is secure against

Security Against Malicious-but-Passive Type II Adversary
We now define a more powerful type II adversary, who is allowed to generate the system parameter and the master secret/public key. This assumes that the third party certifier have already been malicious at the very beginning of the setup stage of the system, rather than being only given the parameter and the master secret/public key honestly generated by the challenger. Such attacks are first introduced to certificateless cryptosystems in [Au et al. 2007A]. In addition to this, even though we say that the certifier is malicious, we also assume (as in [Au et al. 2007A]) that the certifier is passive, in the sense that the certifier would not actively replace the user's public key or corrupt the user's secret key. It is shown in [Au et al. 2007A] that the malicious-but-passive third party KGC in certificateless cryptosystems like [Al-Riyami and Paterson 2003] can have its master key pair specifically generated so that all the encrypted messages for the target victim can also be decrypted by the KGC. The security model of certificate-based encryption in [Gentry 2003] also captures the essence of those attacks. The security of certificate-based signatures against a maliciousbut-passive Type II adversary is defined by the following game:

Initial:
The challenger executes A II on the security parameter 1 k . A II returns the system parameters CB-params and master public key CB-mpk. O CB−UserCreate : As defined in Sec. 2.2, this oracle receives an input ID ∈ Γ and outputs the public key CB-P K ID . After obtaining CB-P K ID , a malicious-but-passive Type II adversary must provide ID's certificate Cert ID for (ID, CB-P K ID ). This oracle then adds (ID, CB-SK ID , CB-P K ID , Cert ID ) to L1 P K , and (ID, CB-P K ID , Cert ID ) to L2 P K .

Queries: A malicious-but-passive
O CB−PKReplace : For a malicious-but-passive Type II adversary, the input to this oracle should be (ID, CB-PK, Cert) where Cert is the corresponding certificate of CB-PK under the identity ID. This oracle searches L2 P K , finds a record related to ID and sets CB-P K ID ← CB-PK and Cert ID ← Cert. It then updates the related tuple with (ID, CB-P K ID , Cert ID ).
Output and Restrictions: Same as those defined in Sec. 3.4.
The success probability that an adaptive chosen message and chosen identity malicious-but-passive Type II adversary CB-A II wins the above game is denoted as Succ cma,cida MP −AII ,type , where type ∈ {normal, super}. We say a certificate-based signature scheme is secure against a (t, q UC , q P KR , q C , q S ) malicious-but-passive

Generic Construction of Certificate-based Signatures
In this section, we will introduce a generic method to construct certificate-based signatures. Our construction is based on certificateless signatures whose description is as below.

Syntax of Certificateless Signatures
A certificateless signature (CLS) scheme is defined by six algorithms: CL-Setup (generates KGC's key pair (CL-msk, CL-mpk) and system's parameter), CL-PPKExtract (generates a user ID's partial private key CL-P P K ID ), CL-SSValue (generates a user ID's secret value CL-SV ID ), CL-SPKey (generates a user ID's public key CL-P K ID ), CL-Sign (generates a certificateless signature CL-σ using CL-P P K ID and CL-SV ID ) and CL-Verify (outputs true if a given signature is valid, or f alse otherwise). As one can see, to distinguish from the identity information in the certificate-based system (which is denoted as ID), we use the notion ID to denote the identity information in the certificateless system. For other notations, we put the prefix "CL-" to indicate that they are in the certificateless cryptosystem. Please refer to ] for the formal definition of each algorithm.

Generic Construction: CLS-2-CBS
In this section, we show how to convert a certificateless signature scheme into a certificate-based signature scheme. In our construction, we need a hash function H : Γ × PK CB → ID CL . Here, Γ is the identity information space in the certificate-based system, PK CB is the public key space in certificate-based system and ID CL denotes the space of identities in the certificateless cryptosystem 3 .
Let CLS be the certificateless signature scheme described in Section 4.1. We now describe the generic construction CLS-2-CBS.

CB-Setup(1 k ) → (CB-msk, CB-mpk, CB-params).
(a) Run algorithm CL-Setup(1 k ) of CLS to obtain CL-params, CL-msk and CL-mpk. For the security parameter k, we assume that the public key size in a certificateless cryptosystem is at least 2 k ; (b) Set CB-params by extending CL-params to include the description of Γ ; 3 Here, we use the hash function H to "connect" two identities in certificatebased signatures and certificateless signatures. This is different from the tech- (c) (CB-msk, CB-mpk) ← (CL-msk, CL-mpk).
Correctness. We show that any certificate-based signature produced by CB-Sign will pass through the verification in CB-Verify. In our construction, a certificate-based signature is the output of the algorithm CL-Sign in the certificateless system, and algorithm CB-Verify also employs the verification algorithm CL-Verify in the certificateless system. To show the correctness of our construction, it suffices to show that under the same CL-params and CL-mpk, a certificateless signature produced by using the secret value CL-SV ID and the partial private key CL-P P K ID will pass through the check using the corresponding identity ID and its public key CL-P K ID . This is ensured by the correctness of the underlying certificateless signature scheme, that is, for any signature CL-σ produced by CL-Sign(m, CL-params, CL-mpk, ID, CL-SV ID , CL-P K ID , CL-P P K ID ), CL-Verify(CL-mpk, CL-params, ID, CL-P K ID , (m, CL-σ)) will output true. Therefore, for any signature output by CB-Sign defined in our construction, the algorithm CB-Verify will always output true.

Theorem 1. [Security of CLS-2-CBS] CLS-2-CBS is secure (in the random oracle model) against adversaries defined in Section 3, assuming the underlying certificateless signature scheme CLS satisfying certain security requirements.
The proof of Theorem 1 consists of several lemmas, which demonstrate the security relationship between our generic construction CLS-2-CBS and its underlying certificateless signature scheme CLS. Please refer to ] for security definitions of CLS. ].

Lemma 2 Security against Normal-CB-A I . CLS-2-CBS is secure (in the random oracle model) against Normal-CB-A I defined in Section 3.1, if CLS is secure against Normal-CL-A I defined in
Proof. In the proof, we will regard hash function H as the random oracle and show that if there is a Normal-CB-A I who can forge a valid certificate-based signature of CLS-2-CBS with non-negligible probability, then there exists a Normal-CL-A I who can use Normal-CB-A I to forge a valid certificateless signature of CLS with almost the same probability.
In our proof, the challenger of a Normal-CB-A I is the Normal-CL-A I against the underlying CLS, who can make requests to its own challenger CL-Challenger. CL-Challenger is made up of several oracles as follows: O CL−UserCreate (creates users in the certificateless cryptosystem), O CL−Corruption (returns secret values of created users), O CL−PPKExtract (returns partial private keys of created users), O CL−PKReplace (replaces public keys of created users with the value provided by the adversary) and O CL−NormalSign (returns certificateless signatures on messages chosen by the adversary). Please refer to ] for the formal definition of each oracle. The description of our proof is as follows.

Initial:
The CL-Challenger runs the algorithm CL-Setup of CLS and feeds the Normal-CL-A I with CL-mpk and CL-params. Normal-CL-A I then returns CBmpk and CB-params to Normal-CB-A I where CB-mpk is defined to be CL-mpk and CB-params is defined by extending CL-params to include the description of Γ . Before Normal-CB-A I submits any queries, Normal-CL-A I asks CL-Challenger to create q uc users in the certificateless cryptosystem. Here q uc is the number of queries Normal-CB-A I issues to O CB−UserCreate . Normal-CL-A I then records the information as (ID i , CL-P K IDi ), i = 1, 2, · · · , q uc in the list CL P K . Here ID i ∈ ID CL , CL-P K IDi is the original public key of ID i in certificateless system. Queries: As defined in Section 3.1, Normal-CB-A I can issue queries to following oracles. We now show how Normal-CL-A I can answer these queries.
-RO: In the proof, the hash function H is viewed as the random oracle RO.
For a fresh input (ID,CB-PK) ∈ Γ × PK CB , the output of RO is a random element ID in ID CL . Normal-CL-A I maintains a list L RO consisting of (ID,CB-PK,ID).
-O CB−UserCreate : At any time Normal-CB-A I can request to create the user ID i ∈ Γ and expect to obtain ID i 's public key CB-P K IDi . In response to such queries: 1. For the i th fresh query ID i , Normal-CL-A I first checks the list CL P K and finds the i th pair (ID i , CL-P K IDi ). Normal-CL-A I then sets CB- already appears in L RO , then the simulation fails and Normal-CL-A I aborts. This, however, happens only with negligible probability as |PK CL | is assumed to be greater than 2 k and k is the security parameter. Otherwise, it adds (ID i , ⊥, CB-P K ID i ) into the list L1 P K . Meanwhile, it sets CB-P K ID i ← CB-P K ID i and adds (ID i , CB-P K ID i ) into list L2 P K . Here, the notation ⊥ means that Normal-CL-A I does not know the corresponding secret key CB-SK ID i .
2. In addition to maintain L1 P K , L2 P K , Normal-CL-A I will keep two additional lists L1 ID and L2 ID which will help it answer queries from Normal-CB-A I . L1 ID consists of pairs with the form (ID i , ID i ) where ID i ∈ Γ and ID i ∈ ID CL . This list will help Normal-CL-A I to respond Normal-CB-A I 's corruption queries and NormalSign queries. L2 ID consists of pairs with the form (ID i , ID i ) where ID i ∈ Γ and ID i ∈ ID CL . In different phases, ID i could be the identity ID i in the list L1 P K , or the identity ID i ∈ ID CL created at some time later.
For a user ID i created in this oracle, Normal-CL-A I will add (ID i , ID i ) into list L1 ID , where ID i ∈ ID CL is ID i 's corresponding identity in the list CL P K . Meanwhile, Normal-CL-A I sets ID i ← ID i and adds (ID i , ID i ) into list L2 ID .
-O CB−PKReplace : At any time Normal-CB-A I can replace a public key of a created user ID with the public key CB-P K ID chosen by himself. In response, Normal-CL-A I first sets CB-P K ID $ ← CB-P K ID , then 1. Normal-CL-A I browses the list L2 P K and rewrites the related pair as (ID, CB-P K ID ). It then browses L RO .
2. If (ID, CB-P K ID ) appears in L RO in the tuple (ID, CB-P K ID , ID), Normal-CL-A I will make a user-create query ID to CL-Challenger if ID has not been created in the certificateless system. After that, Normal-CL-A I replaces ID's certificateless public key with CB-P K ID and updates the corresponding pair in CL P K with (ID, CB-P K ID ). Finally, Normal-CL-A I browses the list L2 ID and updates the related pair with (ID, ID).
3. Otherwise, Normal-CL-A I sets H(ID,CB-P K ID )=ID, which is randomly chosen in ID CL . It then adds (ID, CB-P K ID , ID) into L RO . After that, Normal-CL-A I asks CL-Challenger to create the user ID. After creating the identity ID, Normal-CL-A I replaces ID's public key with CB-P K ID . Normal-CL-A I then updates CL P K by adding (ID, CB-P K ID ). Finally, Normal-CL-A I browses the list L2 ID and updates the related pair with (ID, ID).
-O CB−Corruption : At any time Normal-CB-A I can request the secret key of a created user ID i . In response, Normal-CL-A I checks the list L1 ID and finds (ID i , ID i ). Then, it issues a corruption request ID i to CL-Challenger who will return CL-SV IDi to Normal-CL-A I , where CL-SV IDi is the secret value of ID i when it was created in the certificateless system. At last, Normal-CL-A I sets CB-SK ID i ← CL-SV IDi , returns it to Normal-CB-A I and updates the information in the list L1 P K as (ID i , CB-SK ID i , CB-P K ID i ).
Correctness: This oracle should return the user ID i 's original secret key CB-SK ID i when the user was created. Recall that L1 ID contains pairs (ID i , ID i ) i = 1, 2, · · · , q uc , where ID i ∈ ID CL is the ID i 's initial corresponding identity in certificateless system. ID i is set as H(ID i ,CB-P K ID i ) and CL-P K IDi =CB-P K ID i which is the original public key of ID i . Thus the secret value CL-SV IDi of ID i in certificateless system is the same as the secret key CB-SK ID i of ID i in certificate-based system.
-O CB−CertGen : At any time Normal-CB-A I can request the certificate of (ID, CB-PK) where CB-PK is chosen by the adversary itself. Normal-CL-A I will try to find an identity ID ∈ ID CL , whose partial private key is ID's certificate under the public key CB-PK. To do that, Normal-CL-A I will check L RO : 1. If (ID, CB-PK) appears in L RO in the tuple (ID, CB-PK, ID), Normal-CL-A I will make a user-create query ID to CL-Challenger if ID has not been created in certificateless system.

Otherwise, Normal-CL-A I sets H(ID,CB-PK)=ID
, which is randomly chosen in ID CL . It then adds (ID, CB-PK, ID) into L RO . After that, Normal-CL-A I asks CL-Challenger to create the user ID.
For either case, Normal-CL-A I issues the partial private key query ID to CL-Challenger who will return the partial private key CL-P P K ID . At last, Normal-CL-A I sets Cert ID ← CL-P P K ID and returns it to Normal-CB-A I .
-O CB−NormalSign : At any time, Normal-CB-A I can request the signature of (m i , ID i ). The Normal-CL-A I first finds the pair (ID i , ID i ) in the list L1 ID . Then, Normal-CL-A I issues a certificateless signing query (ID i , m i ). As defined, Normal-CL-A I will obtain the signature CL-σ i such that true = CL-Verify(CL-mpk, CL-params, ID i , CL-P K IDi , (m i , CL-σ i )). Normal-CB-A I will set CB-σ i ← CL-σ i , and return CB-σ i as the answer.

Correctness:
Recall that for the pair (ID i , ID i ) in L1 ID , ID i is set as H(ID i ,CB-P K IDi ) and CB-P K IDi = CL-P K IDi . Here, CB-P K IDi is ID i 's original public key in the list L1 P K . Therefore, true =CB-Verify(CB-params, Output: After all queries, CB-A I will output a forgery (m * , CB-σ * , ID * ). If Normal-CB-A I wins game, then: where (ID * , CB-P K ID * ) is in the list L2 P K . Here, CB-P K ID * is ID * 's current public key.

(ID
That is, (ID * , m * ) has never been asked to O CL−NormalSign of CLS.

(ID
That is, ID * has never been asked to O CL−PPKExtract of CLS.
That is, ID * has never been asked to O CL−Corruption of CLS.
If Normal-CL-A I does not fail in the simulation, then it can output a valid forgery (m * , CL-σ * , ID * ) of the underlying certificateless signature scheme with the same success probability as Normal-CB-A I . Considering that Normal-CL-A I could only fail in simulating H as the random oracle, which only happens with negligible probability q UC /2 k (q UC is the number of user-create queries). Thus, Normal-CL-A I wins the game with almost the same probability as Normal-CB-A I . This completes the proof of Lemma 2.
Security against Strong-CB-A I and Super-CB-A I . One can use almost the same technique to prove that our generic construction is secure against Strong-CB-A I (or, Super-CB-A I ), if the underlying certificateless signature scheme is also secure against Strong-CL-A I (or, Super-CL-A I ) defined in ]. The details are thus omitted here. Proof. In the proof, we will regard the hash function H as the random oracle and show that if there is a CB-A II (either Normal-CB-A II or Super-CB-A II ) who can forge a valid certificate-based signature of CLS-2-CBS with non-negligible probability, then there exists a CL-A II (correspondingly, Normal-CL-A II , or Super-CL-A II ) who can use CB-A II to forge a valid certificateless signature of CLS with almost the same probability. In our proof, the challenger of a CB-A II is the CL-A II against the underlying certificateless signature scheme, who can make requests to its own challenger CL-Challenger. The description of our proof is as follows. Initial: The CL-Challenger runs the algorithm CL-Setup of CLS and feeds the CL-A II with CL-msk, CL-mpk and CL-params. CL-A II then returns (CB-msk, CB-mpk) and CB-params to CB-A II where (CB-msk, CB-mpk) is defined to be (CL-msk, CL-mpk) and CB-params is defined by extending CL-params to include the description of Γ . Before CB-A II submits any queries, CL-A II asks CL-Challenger to create q uc users in the certificateless cryptosystem. Here q uc is the number of queries CB-A II issues to O CB−UserCreate . CL-A II then records the information as (ID i , CL-P K IDi ), i = 1, 2, · · · , q uc in the list CL P K . Here ID i ∈ ID CL , CL-P K IDi is the original public key of ID i in certificateless system. Queries: As defined in Section 3.4, CB-A II can issue queries to O CB−UserCreate , . These oracles are simulated by CL-A II in the same way as described in the proof of the security against Type I adversary in Lemma 2. Output: After all queries, CB-A II will output a forgery (m * , CB-σ * , ID * ). If CB-A II wins, then: 1. true = CB−Verify(m * , CB-σ * , CB-params, ID * , CB-P K ID * , CB-mpk), where (ID * , CB-P K ID * ) is in the list L1 P K , that is, CB-P K ID * is ID * 's original public key.

(ID
That is, (ID * , m * ) has never been asked to O CL−Sign of CLS.
That is, ID * has never been asked to O CL−Corruption of CLS.
If CL-A II does not fail in the simulation, then it can output a valid forgery (m * , CL-σ * , ID * ) of the underlying certificateless signature scheme with the same success probability as CB-A II . As in the proof of Lemma 2, CL-A II could only fail in simulating H as the random oracle, which only happens with negligible probability q UC /2 k (q UC is the number of user-create queries). Thus, CL-A II wins the game with almost the same probability as CB-A II . This completes the proof of Lemma 3.

Security Against Malicious-but-Passive Type II Adversary.
One can use almost the same technique to prove that our generic construction is secure against malicious-but-passive CB-A II , if the underlying certificateless signature scheme is also secure against malicious-but-passive CL-A II defined in ]. The details are thus omitted here.

Concrete Examples of CLS-2-CBS
By applying CLS-2-CBS to concrete certificateless signature schemes, we can obtain several new constructions of certificate-based signatures. This section will describe two of them, which are constructed from certificateless signature schemes proposed in ]. We start by reviewing the bilinear groups and the complexity assumption in ].

Bilinear Groups and Security Assumptions
Let G 1 denote an additive group of prime order p and G T be a multiplicative group of the same order. Let P denote a generator in G 1 . Let e : G 1 × G 1 → G T be a bilinear mapping with the following properties: -The map e is bilinear: e(aP, bQ) = e(P, Q) ab for all P, Q ∈ G 1 , a, b ∈ Z Z p .
-The map e is efficiently computable.
We say that (G 1 , G T ) are bilinear groups if there exists the bilinear mapping e : G 1 × G 1 → G T as above, and e, and the group action in G 1 and G T can be computed efficiently.
The success probability of any probabilistic polynomial-time algorithm A in solving CDH problem in G 1 is defined to be Succ CDH A,G1 = Pr[A(P, aP, bP ) = abP ] where the probability is over the random choice of a, b ∈ Z Z p and the random bits consumed by A.

Scheme I
The scheme described in this section is based on the certificateless signature scheme in Section 4.2 of ]. It consists of following algorithms.
-CB-Setup: Let (G 1 , G T ) be bilinear groups where |G 1 | = |G T | = p, for some prime number p ≥ 2 k , where k is the system security number. e denotes the bilinear mapping and H 2 : Γ × G * 1 → ID be three secure cryptographic hash functions, where Γ is the set of identity information in the certificate-based system and ID is the identity space defined in ]. The certifier chooses a random number s ∈ Z Z * p and a generator P of G * 1 . The certifier then calculates system's master public key CB-mpk= sP , where s is the master secret key CB−msk. The system's parameter CB-params is {G 1 , G T , p, e, P, H 0 , H 1 , H 2 , CB-mpk, Γ }.
-CB-UserCreate: The user ID chooses a random number x ID ∈ Z Z * p and sets x ID as the secret key. Here the valid secret key value space is SK CB = Z Z * p . User ID can also calculate the public key CB-P K ID = x ID P . Here the valid public key space is PK CB = G * 1 .
-CB-Sign: For a message m, the user ID setsÎ D = H 2 (ID CB-P K ID ) and computes the signature CB-σ = Cert ID + x ID H 1 (m Î D CB-P K ID ).
-CB-Verify: Given a pair (m, σ) and user ID's public key CB-P K ID , after settingÎ D = H 2 (ID CB-P K ID ), anyone can check whether e(CB-σ, P ) ? = e(H 0 (Î D),CB-mpk)e(H 1 (m Î D CB-P K ID ), CB-P K ID ). If the equality holds, this algorithm outputs true. Otherwise, this algorithm outputs f alse.
Theorem 5 Security of Concrete Scheme I. Scheme I is secure (in the random oracle model) against Normal-CB-A I and Super-CB-A II adaptive chosen message and chosen identity attacks, assuming that CDH problem is hard in G 1 .
Proof. The correctness of this theorem is due to Theorem 1 and the underlying certificateless signature scheme is provably secure (in the random oracle model) against Normal-CL-A I and Super-CL-A II if CDH problem is hard in G 1 ].

Scheme II
The scheme described in this section is based on the certificateless signature scheme in Section 4.3 of ]. The first four algorithms are the same as those defined in Section 5.2, with the only difference that H 1 is defined as {0, 1} * → Z Z p . The CB-Sign and CB-Verify algorithms are described as follows: -CB-Sign: For a message m, the user ID setsÎ D = H 2 (ID CB-P K ID ) and computes the signature σ = (u, v, W ) where • u = H 1 (m Î D CB-P K ID r 1 P e(P, P ) r2 ) for random numbers r 1 , r 2 ∈ Z Z p chosen by user ID; and • v = r 1 − ux ID (mod p), W = r 2 P − uCert ID .
-CB-Verify: Given a message/signature pair (m, σ = (u, v, W )), ID's public key CB−P K ID , by settingÎ D = H 2 (ID CB-P K ID ) anyone can check whether u ?
= H 1 (m Î D CB-P K ID vP + uCB-P K ID e(W, P )e(CB−mpk, H 0 (Î D)) u ). If the equality holds, this algorithm outputs true. Otherwise, this algorithm outputs f alse.
Theorem 6 Security of Concrete Scheme II. Scheme II is secure (in the random oracle model) against Super-CB-A I and Super-CB-A II adaptive chosen message and chosen identity attacks, assuming that CDH problem is hard in G 1 .
Proof. The correctness of this theorem is due to Theorem 1 and the underlying certificateless signature scheme is provably secure (in the random oracle model) against Super-CL-A I and Super-CL-A II if CDH problem is hard in G 1 ].
Remark. Scheme II is the first certificate-based signature scheme which is provably secure against Super Type I and Type II adversary.   [Li et al. 2007] Normal AI and AII Scheme I Normal AI and Super AII CBSa in [Kang et al. 2004] Strong AI and AII Scheme II Super AI and AII

Efficiency Comparison
We now make a comparison among existing certificate-based signature schemes, which are proposed in [Liu et al. 2008, Li et al. 2007, Kang et al. 2004 . When compared to schemes (e.g. the first scheme in [Liu et al. 2008]) without bilinear mapping, our Scheme I and Scheme II have more computational cost but shorter signature length. When compared to schemes (e.g. the second scheme in [Liu et al. 2008]) whose security is proved without random oracles, Scheme I and Scheme II have advantages of shorter system parameter, less computational cost and shorter signature length. The comparison among other schemes with similar constructions as ours is shown in Table 1 and Table 2. The notations in Table 1 are as follows: |G 1 | and |Z Z p | denote the bit length of an element in G 1 and Z Z p , respectively; E denotes the exponentiation in G 1 ; BM and P A denote the bilinear mapping operation and point addition in G 1 , respectively. Table 2, Scheme I and CBS in [Li et al. 2007] have the similar security level (To be more precisely, our Scheme I is provably secure against Normal A I and Super A II , and CBS in [Li et al. 2007] is provably secure against Normal A I and A II ), while Scheme I has less computational operation and shorter signature length . The certificate-based signature scheme CBSa in [Kang et al. 2004] is secure against the adversary similar to the strong adversary defined in this paper, while Scheme II is secure against the super adversary with comparable computational cost and signature length. In addition, the two pairing operations (e(P, P ) and e(CB−mpk, H 0 (Î D))) in Scheme II can be computed in an off-line manner, which can further improve the efficiency of Scheme II. The compari-son shows that by applying our generic construction to efficient certificateless signature schemes, one can obtain new certificate-based signature schemes with better performance than existing ones.

Conclusion
The focus of this paper was on certificate-based signatures. We demonstrated the pros and the cons of certificate-based signatures, by comparing it with digital signatures in other popular public key systems. Then, we defined several new types of adversaries and gave a new security model of certificate-based signatures. Our model is more elaborated by comparison with other existing security models of certificate-based signatures. We proposed a generic construction of certificate-based signatures from certificateless signatures. Our generic construction is secure (in the random oracle model) under the security model proposed in this paper if the underlying certificateless signature scheme satisfies certain security notions. Finally, we gave two concrete instances (with different security levels) of our generic constructions.