Efficient and Secure Certificateless Directed Proxy Signature Scheme without Pairings

Efficient and Secure Certificateless Directed Proxy Signature Scheme without Pairings

R. R. V. Krishna Rao, N.B. Gayathri and P. Vasudeva Reddy

Department of Engineering Mathematics,

Andhra University, Visakhapatnam, Andhra Pradesh, Pin code: 530003, INDIA.

email: [email protected], [email protected],

*

[email protected]

(Received on: April 8, 2019) ABSTRACT

The proxy signature scheme allows a proxy signer to sign the message on behalf of an original signer. However public verifiability of proxy signature is not desirable in some applications where the signed message is sensitive to the signature receiver. To meet this requirement, the concept of directed proxy signature was introduced. A directed proxy signature scheme is a kind of signature scheme, in which the verification ability is controlled by the proxy signer. Many directed proxy signature schemes are proposed in literature with various cryptographic settings.

However, it has been found that all these schemes are designed in Identity-based setting using bilinear pairings over elliptic curves. But the computation of a bilinear pairing is very expensive. Hence, in this paper, we propose the first certificateless directed proxy signature scheme without pairings. We also show our scheme is secure against various types of attacks. Also performance of this scheme is very efficient.

Keywords: Certificateless Signature, Directed Signatures, Proxy Signature, Random Oracle Security Model, Elliptic Curve Discrete Logarithm Problem.

1. INTRODUCTION

Digital signature is one of the fundamental and useful cryptographic primitive, which

provides authentication and non-repudiation for digital communications. To implement the

digital signature in the real world applications, it needs to consider different features and

properties to make them adequate and suitable for different usages. There are many digital

signature schemes in literature with different cryptographic settings such as traditional public

key infrastructure (PKI)

and Identity based cryptosystem

. The security of the traditional PKI is based on the certificate, signed by a certification authority (CA), containing the relationship between the key pairs, i.e., a public key and a private key, and the user’s identity and legitimacy. But certificate management leads to extra storage, large computation and communication costs. Contrast to traditional PKI, Identity Based cryptosystem (IBC)

does not need any certificate to ensure the authenticity of public/private key pair. In this system, public key of a user is derived from the user’s identity and the secret key is generated by a trusted third party called Private Key Generator (PKG). Though IBC successively eliminates the necessity of certificates, it suffers from inherent key escrow problem. Later, Al-Riyami

introduced a novel system called, certificateless public key cryptography (CL-PKC). This approach neither suffers from the key escrow problem nor requires any certificates, and so it can be viewed as a model in between traditional PKI and ID-PKC.

To deal with different scenarios, digital signature schemes have evolved into many variants such as Blind signature, Multi signature, Group signature, Ring signature etc. One of such variants is Proxy signature. A proxy signature scheme is an important cryptographic technique and allows an entity to delegate the signing capability to one or more entities. In 1996, Mambo et al.

introduced the proxy signature scheme, in which the original signer (Alice) delegated his signing privilege to a proxy signer such that the proxy signer (Bob) on behalf of the original signer can sign some specific messages. An entity (Cindy) who receives a message with a proxy signature can easily check the correctness of the signature and be convinced about the agreement of the original signer. Since then many new constructions have been proposed in literature on various cryptographic settings such as PKI based

, ID- based

and Certificateless based

. According to the delegation ways, proxy signature can be classified into three types: full delegation

, partial delegation

, and delegation by warrant

.

However, these proxy signature schemes allow public verification, which might not be suitable for applications in which the verification of the proxy signature is sensitive to the receiver, for example signatures on medical records, tax information. To meet this requirement, Lim and Lee

proposed a new type of signature called Directed signature. In a directed signature scheme, a signer sends a signature on a message to a designated verifier;

only the designated verifier can directly verify the signature, while the others know nothing about validity of the message without the help of the signer or the designated verifier. In case of trouble or if necessary, both signer and the designated verifier can prove the validity of the signature to any third party. Directed signature schemes are very useful in practical applications where signed message is sensitive to the signature receiver. After the introduction of directed signatures by Lim and Lee in

, many directed signature schemes are proposed in PKI based setting

. The first efficient ID-based directed signature scheme was presented by Sun et al.

in the random oracle model. Later few directed signature schemes were proposed in both ID-based setting

and Certificateless based setting

.

The combination of directed signature technique with proxy signature integrates the

advantages of both and is more applicable for signing on sensitive messages. Consider the

following situation: Doctor Alice has issued a hospital record to the patient Bob, in the form

of doctor’s digital signature. Alice can delegate his signing right to the proxy signer (Doctor Charlie). Bob then can exclusively verify these signatures with others knowing nothing about his state of illness. Otherwise, his state of illness is exposed. After a period time, Bob also needs to prove validity of his hospital record to other doctor for cure. At the same time, Doctor Charlie also shares the ability and responsibility to acknowledge this hospital records when Bob may not be convenient to do so. Motivated by the above scenario, some directed proxy signature schemes have been proposed in the literature

. In these schemes, the proxy signer generates a proxy signature on behalf of the original signer to a designated verifier. The designated verifier can directly verify the proxy signature and he can convince any other party about the validity of the signature. All these schemes are designed on Identity based setting.

There is no directed proxy signature scheme in Certificateless based setting.

Moreover, most of the above directed proxy signature schemes are designed using bilinear pairings over elliptic curves. The time consuming cryptographic operation is pairing operation and is more expensive than the evaluation of a scalar multiplication in elliptic curve.

For example, Elliptic Curve Cryptography (ECC) with 224 bit keys provides the same level of security as RSA with 2048 bit keys. Thus ECC has become popular since it provides higher security with smaller keys in size. This smaller key size improves the computational efficiency, storage capacity, bandwidth efficiency. Hence to improve the computational efficiency in directed proxy signature schemes, it is required to design the signature scheme without using bilinear pairing operations. This motivated us to design a pairing free directed proxy signature scheme in Certificateless based setting.

1.1. Our Contribution

Our main contributions in this paper are as follows.

i) We proposed an efficient Certificateless Directed Proxy Signature (CLDPS) scheme.

ii) We designed our CLDPS scheme without using bilinear pairings over elliptic curves. To the best of our knowledge this is the first scheme in Certificateless setting addressing about directed proxy signature in pairing free environment.

iii) The proposed CLDPS scheme is secure against forgeability and visibility. We proved it in random oracle model (ROM) under the hardness of the Elliptic Curve Discrete Logarithm Problem (ECDLP).

iv) We compare our CLDPS scheme with the existing directed signature schemes in terms of computational complexity point of view.

v) Efficiency analysis shows that the proposed CLDPS scheme is much efficient than all other schemes in the literature.

1.2. Organization

The remaining part of this paper is organized as follows. We presented some preliminaries in Section 2. Syntax and security model for our CLDPS scheme are presented in Section 3.

The proposed CLDPS scheme with its security analysis is presented in Section 4. Efficiency

analysis of our scheme is presented in Section 5. Finally Section 6 concludes the paper.

2. PRELIMINARIES

This section we briefly present the fundamental concepts on elliptic curve and the complexity assumption, on which the proposed scheme is designed and achieves the desired security.

2.1 Elliptic Curve Group

An elliptic curve E over a prime finite field F

is defined by an equation

2 3

, ,

y x ax b a b F and

then we define G {( , ) : , x y x y F E x y

, ( , ) 0} { } O as the additive cyclic group and the point ' ' O is the point at infinity

.

Elliptic Curve Discrete Logarithm Problem (ECDLP)

Given a random instance P the generator of G and ^{Q xP} where _{x Z}

_, compute x from P and . Q

Computation of x from P and Q is assumed to be computationally hard by any polynomial-time bounded algorithm.

The following Table 1 presents the Symbols and their descriptions which have been used throughout this paper.

Table 1: Symbols and their descriptions

Symbol Description

,

n s Security parameter and system secret key of Key Generation Centre.

,

p q Prime numbers

F

Finite field over p.

( _p)

E F

Elliptic curve defined on finite field.

*

z

The group with elements 1,2…q-1 under addition modulo q.

G Elliptic curve cyclic group of prime order q with generator P.

KGC Key Generation Centre

ECDLP Elliptic Curve Discrete Logarithm Problem.

CLDPS Certificateless Directed Proxy Signature

, ,

os ps dv

ID ID ID Original Signer’s identity, Proxy Signer’s identity and designated verifier’s identity respectively.

1

,

,

,

,

,

,

H H H H H H H Cryptographic one way hash functions.

, ,

i i i

D SK PK Partial secret key, Secret key and Public key of a user.

S Proxy Signing Key

1, 2

Type-I and Type-II adversaries respectively.

: Challenger An algorithm which solves ECDLP by using adversaries.

A distinguisher to distinguish a valid signature on an adaptively chosen message by the attacker from one randomly drawn from the signature space.

1

,

is a Type-I distinguisher and

is a Type-II distinguisher.

ps

Proxy Signature on a message.

3. SYNTAX AND SECURITY MODEL

This section presents the syntax and security model for our pairing free CLDPS scheme.

3.1 Syntax of CLDPS Scheme

A formal model of the proposed CLDPS scheme consists of six components whose functionalities are described as follows.

Setup: KGC runs this algorithm by taking n Z as input and generates master secret key and master public key and publishes the list of public parameters as params.

Partial Secret Key Gen: KGC runs this algorithm by taking params, master secret key, ID as input and generates D _i . KGC sends a partial secret key D _i to the user through a secure channel.

User Key Generation: Taking master public key, ID, D _i as input, this algorithm generates user's SK PK _i , _i .

Delegation Generation: Taking params, master public key, an original signers identity ID os with its private key D _os , a warrant m _w as input, this algorithm is run by the original signer and generates the delegation on the warrant m _w .

Delegation Verification: Given a delegation on the warrant m _w , the proxy signer verifies and accepts the delegation of original signer if the delegation is valid; rejects otherwise.

Proxy Key Generation: Taking the proxy signer’s private key and the delegation of the original signer, the proxy signer run this algorithm to generate the proxy signing key S . Directed Proxy Signature Generation: This algorithm is run by the proxy signer. The

proxy signer with identity ID _ps generates a signature _ps to a designated verifier with identity ID _dv , on a given message m 0,1

by using params, delegation, partial secret key of the signer D _ps , public and secret key pair of the signer ( PK _ps , SK _ps ), and public key of the verifier PK _v .

Direct Proxy Signature Verification (D.Verify): The Designated Verifier runs this algorithm. To verify a signature

on a message m, this algorithm takes params,

,

, ,

os ps

PK PK PK _dv and ID _os , ID _ps , ID _dv as input, and outputs accept if _ps is valid;

or reject, otherwise.

Public Proxy Signature Verification (P. Verify): To verify a signature

on a message

m, this algorithm takes params, _ps , PK _os , PK _ps , PK _dv , ID _os , ID _ps , ID _dv and an Aid

provided by the proxy signer ID

or the designated verifier ID

as input, and outputs

accept if

is valid; or reject, otherwise.

3.2 Security Model of CLDPS Scheme

As described in

, based on the potential adversary behaviour, we consider the following types of adversaries.

1) Type I Adversary: Key Replacement Attack: The Adversary ₁ does not have access to the master secret key but is able to replace the public key of any user with a value of his choice.

2) Type II Adversary: Malicious KGC Attack: The Adversary ₂ cannot replace the public key of any user, but is able to access to the master secret key.

The security of a CLDPS scheme can be defined by considering the following game played between a challenger and an adversary ₁ , ₂ .

3.2.1 Game I:

- Initialization Phase: The challenger runs Setup algorithm, and generates the systems parameters params, master secret key and master public key. gives them to the . If

= 1 then keeps s secret. Otherwise it sends s to = ₂ . - Queries Phase: In this phase, makes queries on the following oracles.

Reveal Partial Secret Key Oracle: On receiving a partial secret key query on ID from ₁ , computes D _i by taking ID as input and gives this to ₁ .

Create User Oracle: On receiving a query from , the challenger computes PK _i by taking ID as input and gives this to .

Reveal Secret Key Oracle: After receiving a query from , the challenger returns SK i by taking ID as input.

Replace Public Key Oracle: Taking identity ID, ₁ may replace current PK _i with the required PK _i .

Delegation Generation Queries: On receiving a query from , the challenger computes delegation by taking original signers identity ID _i and a warrant m _w .

Proxy Key Generation Queries: When queries a Proxy Key of the proxy signer for a delegation with warrant m _w , computes the proxy signing key S _ps and responds to with S _ps .

Proxy Sign Oracle: When makes a signing oracle on ( ID _os , ID _ps , ID _dv , m m _w , ),

returns a valid signature _ps signed by current public/private key of the user ID _ps , for the

input ID _os , ID _ps , ID _dv with message m 0,1 . ^*

D.Verify Oracle: On receiving a query from adversary with ( ID

, ID

, ID

, m m

, ), verifies _ps by extracting ID _dv ' s private key D _dv , SK _dv and returns 1 if is valid.

Otherwise it returns 0.

P.Verify Oracle: On receiving a query from adversary with ( ID

, ID

, ID

, m m

, ), verifies the signature _ps and returns to if _ps is invalid. Otherwise, produces an Aid in the name of the signer ID _ps or the designated verifier ID _dv , then forwards Aid to . - Forgery Phase: Finally outputs ( , m m ^* _w , ^* _ps ) or ( m ^* _w , ID _os ^* , PK ^* _os , ID ^* _ps , ^* , ^* ) where

( W

, V

, k

, ID

, PK

, ID

, PK

,

) as its forgery.

We say wins the game, if one of the following conditions is satisfied.

CASE 1: outputs the tuple ( m ^* _w , ID _os ^* , PK _os ^* , ID ^* _ps , ^* , ^* ) satisfying:

(i) The tuple ( m ^* _w , ID _os ^* , PK _os ^* , ID ^* _ps , ^* , ^* ) is a valid tuple.

(ii) If = ₁ , ID _os ^* has never been made Partial Secret Key Oracle. If = ₂ ,

*

ID os has never been made Secret Key Oracle.

(iii) ( m ^* _w , ID _os ^* , PK _os ^* , ^* ) has never been made Delegation Generation queries.

CASE2: outputs ( , m m ^* _w , ^* _ps ) where

( W

, V

, k

, ID

, PK

, ID

, PK

,

) satisfying:

(i) The tuple ( , m m

,

) where

( W

, V

, k

, ID

, PK

, ID

, PK

,

) is a valid tuple.

(ii) If = ₁ , ID

has never been made Partial Secret Key Oracle. If =

,

*

ID os has never been made Secret Key Oracle.

(iii) ( m

, ID

, PK

,

) has never been made Delegation Generation queries.

(iv) ( m

, ID

, PK

, ID

, PK

) has never been made Proxy Key Generation queries.

(v) ( , m m

, ID

, PK

, ID

, PK

) has never been made Proxy Sign queries.

CASE 3: outputs ( , m m

,

) where

_{( W}

_{, V}

_{, k}

_{, ID}

_{, PK}

_{, ID}

_{, PK}

_,

₎ satisfying:

(i) The tuple ( , m m

,

) where

( W

, V

, k

, ID

, PK

, ID

, PK

,

) is a

valid tuple.

(ii) If = ₁ , ID ^* _ps has never been made Partial Secret Key Oracle. If = ₂ ,

*

ID ps has never been made Secret Key Oracle.

(iii) ( m ^* _w , ID _os ^* , PK _os ^* , ID ^* _ps , PK ^* _ps ) has never been made Proxy Key Generation queries.

(v) ( , m m ^* _w , ID _os ^* , PK _os ^* , ID ^* _ps , PK ^* _ps ) has never been made Proxy Sign queries.

Definition 1: (Unforgeability): A CLDPS scheme is EUF-CMA, if no probabilistic polynomial-time adversary (Type-I and Type-II) has non-negligible probability to win the above game.

Definition 2(Invisibility): Invisibility of CLDPS scheme can be defined by considering the following Game-II against Type-I and Type-II adversaries.

3.2.2 Game II: This game is executed between the challenger and a distinguisher

1 2

( or ) as follows.

Initialization Phase: Same as in Game I.

Phase 1:

In this phase, the challenger responds to the queries asked by distinguisher

1 2

( or ) in the same way as in Game I.

Challenge:

After Phase I is over, ( ₁ or ₂ ) _submits ID ^* _ps , ID ^* _dv , and a message m ^* to the challenger with the condition that

(i) ID _dv ^* has never been submitted to Partial Secret Key Oracle for ₁ . (ii) ID _dv ^* has not been submitted to Secret Key Oracle for ₂ .

(iii) ID _dv ^* has not been submitted to Delegation Generation queries and Proxy Sign queries.

The Challenger then generates a random bit b {0,1} and does the following.

(i) If b 1 then produces a signature ^* _ps .

(ii) If b 0 then selects a random ^* _ps from the signature space.

Finally, sends ^* _ps to ( ₁ or ₂ ).

Phase 2: As in Phase 1, ( ₁ or ₂ ) again adaptively performs several

queries to the challenger , subjected to the following conditions:

1 cannot run Delegation Generation queries and Partial Secret Key Oracle on ID ^* _dv ; and D.Verifiy or P.Verifiy Oracle on ( ID ^* _ps , ID ^* _dv , m ^* ).

2 cannot run Secret Key Oracle on ID _dv ^* ; and D.Verifiy or P.Verifiy Oracle on

* * *

( ID _ps , ID _dv , m ).

Guess: Finally ( ₁ or ₂ ) outputs a bit b {0,1}.

1 2

( or ) succeeds if b b .

4. PROPOSED CLDPS SCHEME WITHOUT PAIRINGS

In this section, we present our efficient CLDPS scheme and we prove its security.

4.1 CLDPS Scheme

As discussed in section 3.1, our CLDPS scheme consists of the following nine algorithms. The functionalities of these algorithms are presented below.

Setup: KGC run this algorithm with the security parameter n Z as input and performs the following.

1. KGC chooses a group G of elliptic curve points with prime order q , a generator P of ,

G and hash functions H H ₁ , ₂ , H ₂ , H H ₃ , ₃ , H ₄ , H ₄ : 0,1 ^* Z _q ^* .

2. KGC chooses a random s Z ^* _q as the master secret key and sets the master public key of the system as P _Pub sP .

3. KGC publish the system parameters as

1 2 2 3 3 4 4

, , ,

, , , , , , ,

params q G P P H H H H H H H and keeps s secretly.

Partial Secret Key Gen: By taking ID _u and system parameters params as input, KGC chooses a random number r _u Z ^* _q , computes R _u r P h _u , _{1 u} H ID R P ₁ ( _u , _u , _Pub ) and

1 mod .

u u u

d r sh q Finally KGC sends the partial secret key D _u ( d R _u , _u ) secretly to the user. The user verifies the equation d P _u R _u h P _{1 u Pub} to check the validity of D _u .

User Key Gen: A user with identity ID _u , randomly chooses a secret value x _u Z _q ^* , and computes X _u x P _u . Set PK _u ( X _u , R _u ) as public key and SK _u ( d _u , x _u ) as its secret key.

Delegation Generation: The original signer creates a warrant m _w which keeps the record

of proxy information such as the identities of the original signer, proxy signer, proxy validity

period and so on. Original signer choose a random number Z _q ^* and computes P ,

2_os 2

(

, ,

),

h H m ID h

H

( m

, , ID

) and h _{2 os os} d h _{2 os os} x mod . q Original signer outputs ( ID _os , PK _os , ID _ps , m _w , , ) as delegation on the warrant m _w and send it to the proxy signer for verification and proxy key generation.

Delegation Verification: Given a delegation ( ID _os , PK _os , ID _ps , m _w , , ), proxy signer does the following.

Computes h _{2 os} H m ₂ ( _w , , ID _ps ), h _{2 os} H ₂ ( m _w , , ID _ps ) and checks whether the equation P h _{2 os} ( R _os h _{1 os Pub} P ) h _{2 os} X _os holds or not. If it holds, proxy signer accepts the delegation , corresponding to ID _os , PK _os , ID _ps , on m _w . Otherwise rejects it.

Proxy Key Generation: After validating the delegation , , proxy signer generates the proxy signing key by using original signer’s delegation key and proxy signer’s private key

( , )

ps ps ps

SK d x as follows.

1. Compute h _{3 ps} H m ₃ ( _w , , ID _os , PK _ps ), h _{3 ps} H ₃ ( m _w , , ID _os , PK _ps ) 2. Compute S h _{3 ps ps} d h _{3 ps ps} x mod q where d _ps r _ps h _{1 ps} s mod . q Hence the proxy signing key (for the original signer) is S .

Proxy Signature Generation: To generate a valid directed proxy signature _s on a given message m 0,1 , ^* proxy signer takes designated verifiers identity ID _dv with public key

dv ,

PK and proxy signing key S as input along with the proxy signers identity ID _ps , and public key PK _ps and does as follows.

1. The proxy signer chooses _{t t}

_{, Z}

and computes U

t P V

,

t P W

,

U

t X

. 2. Compute _h

_{H m m ID}

_{( ,}

_,

_{, ID}

_{, U}

_{, R}

₎ and _h

_H

_{( , m m}

_{, ID}

_{, ID}

_{, U}

_{, R}

_{, h}

_).

3. The signer computes k _ps h _{4 ps} S h _{4 ps} t ₂ mod . q

Hence the directed proxy signature is _ps ( W _ps , V _ps , k _ps , ID _os , PK _os , ). The proxy signer sends the proxy signature ( m m _w , , _ps ) to the designated verifier for verification.

D. Proxy Signature Verification: To accept or reject the directed proxy signature ( m _w , , m _ps ), designated verifier takes params, ID _dv , PK _dv ( X _dv , R _dv ), ID _ps ,

( , )

ps ps ps

PK X R as input and verifies the signature as follows.

Compute Y _dv W _ps x V _{dv ps} U _ps .

Compute h _{4 ps} H m m ₄ ( , _w , ID _ps , ID _dv , Y _dv , R _ps ) and

4 _ps 4 ( , _w , _ps , _dv , _dv , _ps , 4 _ps ).

h H m m ID ID Y R h

Designated verifier verifies the following equation.

4 2

(

)

(

)

(

)

.

ps ps os os os Pub ps ps ps Pub os os ps ps ps ps ps

k P h h R h P h R h P h X h h X h V

If the equation holds, the designated verifier accepts the signature ( m _w , , m _ps ), and outputs 1; rejects and outputs 0 otherwise.

P. Proxy Signature Verification: Any fourth party other than designated verifier can check the validity of proxy signature with the help of the aid provided by designated verifier or proxy signer. Public verifier takes params, ( m _w , , m _ps ), ID _dv , PK _dv ( X _dv , R _dv ),

ps ,

ID PK _ps ( X _ps , R _ps ) as input and does the following.

Either the proxy signer (with identity ID _ps ) or the designated verifier (with identity ID _dv ) computes Aid U _ps Y _dv , and then sends to the fourth party (FP). FP computes

4 _ps 4 ( , _w , _ps , _dv , _dv , _ps )

h H m m ID ID Y R and h _{4 ps} H ₄ ( , m m _w , ID _ps , ID _dv , Y _dv , R _ps , h _{4 ps} ) and then checks whether the equation

4 2

(

)

(

)

(

)

ps ps os os os Pub ps ps ps Pub os os ps ps ps ps ps

k P h h R h P h R h P h X h h X h V

holds.

If it holds, return 1; else 0.

Correctness of the proposed scheme:

The correctness of the scheme can be verified as follows.

4 4 2

4 3 3 4 2

4 2 2 3 3 4 2

4 2 1 2 3 1 3 4

mod .

( ) mod

( )+ mod

( ) ( )

ps ps ps

ps ps ps ps ps ps

ps os os os os ps ps ps ps ps

ps os os os Pub os os ps ps ps Pub ps ps ps ps

k P h S h t P q

h h d h x P h t P q

h h d h x h d h x P h t P q

h h R h P h X h R h P h X h V

h

4 2 1 3 1 2 4 3 4

( ) ( ) ( )

( ) ( ) ( ) .

ps ps ps ps ps ps os os os Pub ps ps ps Pub os os

ps ps os os os Pub ps ps ps Pub os os ps ps ps ps ps

h X h V h h R h P h R h P h X

k P h h R h P h R h P h X h h X h V

4.2 Security of our CLDPS Scheme

In the following we will analyse the security of our CLDPS scheme. We prove the

unforgeability and invisibility of our CLDPS scheme by the following two theorems.

4.2.1 Unforgeability against Type I and Type II adversaries

Theorem 1: If there exists a probabilistic polynomial time bounded adversary who can break our proposed CLDPS scheme under the adaptively chosen message and identity attacks in the ROM, then there exists an algorithm that can be used by to solve the ECDLP.

Proof: We prove Theorem 1 with the help of the following lemma 1 and lemma 2.

Lemma 1: Our CLDPS scheme is existentially unforgeable against Type I adversary in random oracle model if ECDLP is intractable.

Proof: Let be an ECDLP challenger and is given a random instance ( , P Q sP ) of the ECDLP problem in G for a randomly chosen s Z _q ^* . Its goal is to compute s . Let ₁ is a Type-I adversary who interacts with as modelled in Game I. Now we prove that can solve the ECDLP using ₁ . During the simulation process needs to guess the target identity of ₁ . Without loss of generality, takes

as target identity of

on a message m ^* . - Initialization Phase: Algorithm sets P _Pub Q sP and runs Setup algorithm to generate params . then gives params and master public key to ₁ and keeps s secretly.

- Queries Phase: In this query phase, answers a series of queries performed by ₁ in the following way.

Queries on oracle H ₁ H ID R P ₁ ( _u , _u , _Pub ) : maintains an initially empty list L ₁ and has the tuples of the form ( ID R P _u , _u , _Pub , l _{1 u} ). When ₁ makes an H ₁ query on ( ID R P _u , _u , _Pub ),

will check whether the tuple ( ID R P _u , _u , _Pub , l _{1 u} ) is in the list or not. If this tuple exists in L 1 , then returns l _{1 u} . Otherwise, picks a random l _1u and adds to L ₁ . Finally, returns l _{1 u} . Queries on oracle H ₂ H m ₂ ( _w , , ID _u ) : maintains an initially empty list L ₂ and has the tuples of the form ( m _w , , ID l _u , _{2 u} ). When ₁ makes an H ₂ query on ( m _w , , ID _u ), will check whether the tuple ( m _w , , ID l _u , _{2 u} ) is in the list or not. If such a tuple

( m _w , , ID l _u , 2 _u ) exists in L ₂ , ^returns l 2 _u . Otherwise, picks a random l _2u Z _q ^* and returns l _{2 u} . adds ( m _w , , ID l _u , _{2 u} ) to L ₂ .

Queries on oracle H ₂ H ₂ ( m _w , , ID _u ) : maintains an initially empty list L ₂ and has the

tuples of the form ( m _w , , ID l _u , _{2 u} ). When ₁ makes an H ₂ query on ( m _w , , ID _u ),

will check whether the tuple ( m _w , , ID l _u , _{2 u} ) is in the list or not. If such a tuple

( m _w , , ID l _u , 2 _u ) exists in L ₂ , ^returns l 2 _u . Otherwise, picks a random l _2u Z ^* _q and returns l _{2 u} . adds ( m _w , , ID l _u , _{2 u} ) to L ₂ .

Queries on oracle H ₃ H m ₃ ( _w , , ID PK _u , _u ) : maintains an initially empty list L ₃ ^and has the tuples of the form ( m _w , , ID PK l _u , _u , _{3 u} ). When ₁ makes an H ₃ query on ( m _w , , ID PK _u , _u ), will check whether the tuple ( m _w , , ID PK l _u , _u , _{3 u} ) is in the list or not. If such a tuple ( m _w , , ID PK l _u , _u , _{3 u} ) exists in L ₃ , ^returns l 3 _u . Otherwise, picks a random l _3u Z _q ^* and returns l _{3 u} . adds ( m _w , , ID PK l _u , _u , _{3 u} ) to L ₃ .

Queries on oracle H _{3 H}

_{( m}

_{, , ID}

_{, PK}

₎ : maintains an initially empty list L ₃ ^and has the tuples of the form ( m _w , , ID PK l _u , _u , _{3 u} ). When ₁ makes an H ₃ query on ( m _w , , ID PK _u , _u ), will check whether the tuple ( m _w , , ID PK l _u , _u , _{3 u} ) is in the list or not. If such a tuple ( m _w , , ID PK l _u , _u , _{3 u} ) exists in L ₃ , ^returns l _{3 u} . Otherwise, picks a random l _3u Z _q ^* and returns l _{3 u} . adds ( m _w , , ID PK l _u , _u , _{3 u} ) to L ₃ .

Queries on oracle H ₄ H

( , m m

, ID

, ID

, U

, R

, l

) : maintains an initially empty list L ₄ and has the tuples of the form ( , m m _w , ID _ps , ID _dv , U _ps , R _ps , l _{4 u} ). When ₁ makes an H ₄ query on ( , m m _w , ID _ps , ID _dv , U _ps , R _ps ), will check whether the tuple

( , m m _w , ID _ps , ID _dv , U _ps , R _ps , l 4 _u ) is in the list or not. If the tuple exists on L ₄ , then gives

4 _u .

l Otherwise, picks a random l _4u Z _q ^* and returns l _{4 u} . Finally, adds ( , m m _w , ID _ps , ID _dv , U _ps , R _ps , l 4 _u ) to L ₄ .

Queries on oracle H ₄ H ₄ ( , m m _w , ID _ps , ID _dv , U _ps , R _ps , l _{4 u} ) : maintains an initially empty list L ₄ and has the tuples of the form ( , m m _w , ID _ps , ID _dv , U _ps , R _ps , l _{4 u} , l _{4 u} ). When

1 makes an H ₄ query on ( , m m _w , ID _ps , ID _dv , U _ps , R _ps , l _{4 u} ), will check whether the tuple ( , m m _w , ID _ps , ID _dv , U _ps , R _ps , l _{4 u} , l _{4 u} ) is in the list or not. If the tuple exists on

4 ,

L then gives l _{4 u} . Otherwise, picks a random l _4u Z _q ^* and returns l _{4 u} . Finally, adds

4 4

( , m m _w , ID _ps , ID _dv , U _ps , R _ps , l _u , l _u ) to L ₄ .

Reveal Partial Secret Key Oracle PSK ID ( _u ) : To respond to this oracle, maintains an initially empty list L _PSK and has the tuples of the form ( ID d R _u , _u , _u ). When ₁ makes a query on PSK ID ( _u ) then gives d _u , if the query has been made earlier. Otherwise, if

* ,

ID u ID chooses a _u Z _q ^* and sets d _u a _u and add ( ID d R _u , _u , _u ) to L _PSK and returns

u .

d If ID _u ID ^* , aborts.

Create User Oracle Cuser ID ( _u ) : To respond Create User Oracle ID _u , maintains an initially empty list L _Cuser and has the tuples of the form ( ID x PK _u , _u , _u ). When ₁ makes a query on Cuser ID ( _u ), searches the list L _Cuser and outputs PK _u if the query has been made earlier. Otherwise, does as follows.

i) If ID _u ID ^* , generates three random numbers a b x _u , _u , _u Z _q ^* and sets

, 1 ( , , ) and .

u u u Pub u u Pub u u u

R a P b P H ID R P b X x P sets PK _u ( X _u , R _u ) and adds ( ID R P

,

,

, b to

) L ₁ and ( ID x PK

,

,

) to L

. returns

to

as a response.

Note that ( R X _u , _u , h _{1 u} ) generated in this way satisfies the equation d P _u R _u h P _{1 u Pub} . ii) If ID _u ID ^* , generates three random numbers a _ui , b x _u , _u Z _q ^* and sets

, 1 ( , , ) and .

u u u u Pub u u u

R a P H ID R P b X x P sets PK _u X _u , R _u and adds ( ID R P _u , _u , _Pub , b _u ) to L ₁ ^and ( ID x PK _u , _u , _u ) to L _Cuser . ^returns PK u to ₁ as a response.

Reveal Secret Key Oracle RSK ID ( _u ) : When ₁ makes this query on RSK ID ( _u ), if

* ,

ID u ID aborts. Otherwise, if ID _u ID ^* , finds the tuples ( ID x PK _u , _u , _u ),( ID d R _u , _u , _u ) from L _Cuser , L _PSK respectively and recovers x d _u , _u . sets SK _u d _u , x _u and returns SK _u to ₁ . If there is no corresponding tuples in L _Cuser , L _PSK , makes a query on

( _u ),

Cuser ID to generate x _u , and makes a query on PSK ID ( _u ) to generate d _u . saves these values in L _Cuser , L _PSK respectively. Finally returns SK _u .

Replace Public Key Oracle RPK ID ( _u ) : When adversary makes a query on RPK ID ( _u ), finds ( ID x PK _u , _u , _u ) in L _Cuser . replaces PK _u PK _u and x _u .

Queries on Delegation Genration: When ₁ makes this query on ( m _w , ID _os , ID _ps ),

generates two random numbers _os , _os Z _q ^* , computes h _{1 os} H ID ₁ ( _os , R _os , P _Pub ),

2 _os 2 ( _w , , _ps ),

h H m ID and _os P _os ( R _os h _{1 os pub} P ) h _{2 os} X _os . sets

and 2 .

os h os os At last returns , to ₁ and adds the tuple ( m _w , , ID _os , _os ) to list L ₂ .

Note that delegation , generated in this way satisfies the equation

2 _os ( _o 1 _{os Pub} ) 2 _{os os} .

P h R h P h X

Queries on Proxy Key Generation: When ₁ makes this query on ( m _w , ID _os , ID _ps ), gets , through Delegation Generation queries. If ID _ps ID ^* , stops the simulation.

Otherwise, finds the tuples ( ID _ps , x _ps , PK _ps ), ( ID _ps , d _ps , R _ps ) from L _Cuser , L _PSK respectively and recovers x _ps , d _ps . Also recovers ( m _w , , ID PK l _u , _u , _{3 u} ),

( m _w , , ID PK l _u , _u , 3 _u ) from L L ₃ , ₃ and computes S h _{3 ps} d _ps h _{3 ps ps} x mod . q returns the proxy key as S to ₁ .

Signing Oracle: When ₁ makes this query on ( , m m _w , ID _os , ID _ps ), with a verifier ID _dv , first makes queries on H H ₁ , ₂ , H ₂ , H H ₃ , ₃ , H ₄ , H ₄ oracles for u os or ps , and recovers the tuples ( ID R P _u , _u , _Pub , l _{1 u} ), ( m _w , , ID l _u , _{2 u} ), ( m _w , , ID l _u , _{2 u} ),

( m _w , , ID PK l _u , _u , 3 _u ), ( m _w , , ID PK l _u , _u , _{3 u} ) ( , m m _w , ID _ps , ID _dv , U _ps , R _ps , l _{4 u} ),

4 4

( , m m _w , ID _ps , ID _dv , U _ps , R _ps , l _u , l _u ) from L L L ,L L L L ₁ , ₂ , _{2 3} , ₃ , ₄ , ₄ respectively and ( ID d _u , _u , R _u ) from L _PSK ^{and (} ID x PK u ^, u ^, u ⁾ from L _Cuser . generates two random numbers r _{1 ps} , r _{2 ps} Z _q ^* and sets k _ps r _{1 ps} , V _ps l _{4 ps} ¹ r _{1 ps} P l _{3 ps} l _{4 ps} X _ps ,

2 and 2 ,

ps ps dv ps ps

U r X W r P

2 _{os os} 1 _{os pub} 3 _{ps ps} 1 _{ps pub} 2 _{os os} ,

l R l P l R P l P l X returns

( , , , , , )

ps W ps V ps k ps ID os PK os to ₁ .

Note that ( , m m _w , _ps ) generated in this way satisfies the verification equation

4 2

(

)

(

)

(

)

. (1)

ps ps os os os Pub ps ps ps Pub os os ps ps ps ps ps

k P h h R h P h R h P h X h h X h V

D. Verify Oracle DV ID ( _u ) : When ₁ submits ( , m m _w , ID _os , ID _ps , ID _dv ), and

( , m m _w , _ps ) where _ps ( W _ps , V _ps , k _ps , ID _os , R _os , ) to , first recovers

( ID _dv , R _dv , P _Pub , l 1 _dv ) from L ₁ list and then proceeds as follows.

i) If ID _dv ID ^* then computes U _ps x W _{dv ps} and recovers the corresponding tuples from L L ₄ , ₄ lists. If these tuples does not exists, selects l _{4 u} , l _{4 u} Z _q ^* and defines

4

( ,

,

,

,

,

,

)

H m m ID ID U R l l and H

( , m m

, ID

, ID

, U

, R

, l

, l

) l

. then verifies the equation (1) with ( , m m _w , _ps ) and returns 1 if _i valid; otherwise returns 0.

ii) If ID _dv ID ^* , works on all possible entries H m m ₄ ( , _w , ID _ps , ID _dv , U _ps , R _ps , l _{4 u} ) and H ₄ ( , m m _w , ID _ps , ID _dv , U _ps , R _ps , l _{4 u} , l _{4 u} ) for some U _i .

a) For each possible entry H m m ₄ ( , _w , ID _ps , ID _dv , U _ps , R _ps , l _{4 u} ) l _{4 u} and

4 ( , _w , _ps , _dv , _ps , _ps , 4 _u , 4 _u ) 4 _u

H m m ID ID U R l l l for some U _i , evaluates the equation (1) and returns 1(if _i valid) or 0 (if _i invalid) to ₁ .

b) If the above operation does not lead to return an answer for ₁ , then returns 0 (invalid) to ₁ .

P. Verify Oracle PV ID ( _u ) : ₁ submits ( , m m _w , ID _os , ID _ps , ID _dv ), and ( , m m _w , _ps ) to . It then executes the same procedure as in D. Verify Oracle. The only difference is; when

judges _ps ( W _ps , V _ps , k _ps , ID _os , R _os , ) is valid (i.e., returns 1 in the D. Verify Oracle);

it returns Aid U _ps r _{2 ps} X _dv x W _{dv ps} Y _ps (say) to ₁ . When judges ( , m m _w , _ps ) is invalid (i.e., returns 0 in the D .Verify Oracle); it returns to ₁ .

- Forgery: Finally ₁ outputs ( , m m ^* _w , ^* _ps ) where

* * * * * * * * *

( , , , , , , , )

ps W ps V ps k ps ID os PK os ID ps PK ps or ( m ^* _w , ID _os ^* , PK _os ^* , ID ^* _ps , ^* , ^* ) as its forgery.

CASE 1: The output is a valid tuple ( m ^* _w , ID _os ^* , PK _os ^* , ID ^* _ps , ^* , ^* ) satisfying case 1 as defined in Section 3.2.1. If ID _os ^* ID ^* , stops simulation. Otherwise, finds the tuples

* * * * * *

( ID _os , x _os , PK _os ), ( ID _os , d _os , R _os ) from L _Cuser , L _PSK respectively and recovers x ^* _os , PK _os ^* . Note that the public key PK ^* _os may be replaced by ₁ . Let ( PK _os ^* , ^* , ^*

) denote

* * *

( PK _os , , ). By using Forking Lemma

, if we have a replay of with same random tape