Malleability and ownership of proxy signatures: Towards a stronger definition and its limitations

Proxy signature is a cryptographic primitive that allows an entity to delegate singing rights to another entity. Noticing the ad-hoc nature of security analysis prevalent in the existing literature, Boldyreva, Palacio and Warinschi proposed a formal security model for proxy signature. We revisit their proposed security definition in the context of the most natural construction of proxy signature – delegation-by-certificate. Our analysis indicates certain limitations of their definition that arise due to malleability of proxy signature as well as signature ownership in the context of standard signature. We propose a stronger definition of proxy signature to address these issues. However, we observe that the natural reductionist security argument of the delegation-by certificate proxy signature construction under this definition seems to require a rather unnatural security property for a standard signature.


Introduction
Proxy signature allows an original signer, sometimes referred to as the designator, to delegate limited signing rights to another entity called the proxy signer. Such delegation has potential applications in diverse areas: from global distribution networks [1] to grid computing [11].
The notion of proxy signature was introduced by Mambo, Usuda and Okamoto [19]. Since then several schemes have been proposed but many of them were subsequently broken. Boldyreva, Palacio and Warinschi [7] provide a brief narrative of this initial development. They contend that there is a void in terms of rigorous formal treatment of proxy signature and the preliminary version of their work [6] is claimed to be the first one in the paradigm of provable security. The main contributions of [7] are a formal security model that, according to the authors, allows for a rather powerful adversary and several constructions of proxy signature which can be formally shown to be secure in the proposed security model.
In this work we revisit the security notion of proxy signature as formulated in [7]. In particular we undertake a critical analysis of the formal definition in [7] to understand to what extent it captures the potential use and threats in realistic context. Our work is in the spirit of Koblitz and Menezes [17] who raise some pertinent questions on the problem of formulating right definitions in cryptography, including that of a digital signature.
Standard security definition of signature schemes [13,14] deals with the question of unforgeability and hence, non-repudiation assuming there is only one signer in the system. There are several other works that point out limitations of the standard definition of digital signature [21,27,24]. It is also known that a secure signature scheme when combined with other primitives may result in overall security failure [5]. One of the concerns is that the standard definition [13,14] does not take into account the realistic multi-user setting. A distinguishing feature of the latter is that of signature ownership. For example, an adversary can claim ownership of a signature generated by an honest signer.
Such an attack scenario, observed first in the context of a key agreement protocol, was termed as a Duplicate Signature Key Selection (DSKS) attack [5]. In a DSKS attack, given the signature σ of signer Alice on some message m under her certified public key pk, an attacker Mallory generates a certified public key pk such that the same message-signature pair (m, σ) verifies under pk . DSKS attacks on several signature schemes, including RSA and ECDSA as well as ways to thwart such attacks were discussed in [21]. Also see [17] for a detailed discussion on DSKS and its real-world impact. It is worth noting that these attacks show that the question of signature ownership may require additional assumptions beyond what is mandated by unforgeability of signature. For example, even though ECDSA remains unforgeable assuming the intractability of ECDLP, one can still mount a DSKS attack without violating that assumption.
Proxy signature by definition involves two signers -the designator (original signer) and a proxy who signs on behalf of the designator. So we find it pertinent to ask whether signature ownership (and DSKS type of attack) could be of any relevance in the context of proxy signature security. To delve into this question here we first recall (informally) the natural delegation-by-certificate construction of proxy signature [7]. The construction assumes the existence of a standard signature scheme. Suppose the proxy designator, Alice, wants to designate the proxy signer, Bob to sign a message M ∈ ω on her behalf. Alice first generates a warrant wrnt which consists of her signature on a message containing the public key of Bob along with some associated information such as a description of the message space ω. Bob uses his signing key to generate a signature σ on an augmented message that includes the public key of Alice. The proxy signature on M is now pΣ = (wrnt, σ). It's worth noting that by definition pΣ consists of two components and thus opens up the possibility of malleability. Verification of proxy signature pΣ involves checking whether wrnt and σ are valid signatures for the respective messages under the corresponding public keys of Alice and Bob.
The formal security definition in [7] considers only one honest signer -either in the role of proxy designator or proxy signer and does not deal with the question of signature ownership or DSKS type attack. Informally speaking, security of the above delegnation-by-certificate construction essentially means that an adversary cannot generate a new valid proxy signature on behalf of either the honest designator Alice or the honest proxy signer Bob.
We notice that not taking into account the question of signature ownership properly may lead to insecurity of the delegation-by-certificate construction. This point is illustrated in the paper through the example of ECDSA as standardized in FIPS186-4 [23]. In particular, given a proxy signature pΣ = (wrnt, σ) for some M ∈ ω where both designator (Alice) and proxy signer (Bob) are honest, an adversary can come up with another proxy designator Mallory and a valid proxy signature pΣ = (wrnt , σ) for same M ∈ ω where wrnt is the signature of Mallory designating Bob.
Interestingly this attack can be interpreted in two different ways. From the perspective of honest proxy signer Bob, the attack amounts to a forgery of proxy signature and thus contradicts the security claim of delegation-by-certificate construction of [7]. On the other hand, for honest designator Alice this attack violates a desirable security goal of proxy signature which is not formalized in the security model of [7].
In order to address such security concerns we extend the definition of proxy signature by taking into account the ownership issue in the multi-user setting. Despite that we identify a general problem related to proxy signature, which stems from the definition of standard signature security. It appears that a natural definition of proxy signature security requires a rather unnatural security definition for standard signatures. Thus our work provides further evidence to the critique in [17], namely a theoretically accepted definition within the paradigm of provable security may have shortcomings in practice.
1.1. Outline of the paper. In §2 we argue for a stronger security definition of proxy signatures through some plausible attack scenarios on the delegation-bycertificate construction of [7]. The first attack scenario demonstrates how an adversarially generated public key can use the malleability property of proxy signatures to generate a forgery according to the security definition of [7]. The second scenario points out a deficiency in the security definition of proxy signature in [7]. Together they demonstrate a connection between malleability and insecurity of (proxy) signature. We conclude with a description of what a stronger definition should aim at to capture such scenarios.
In §3 we describe our proposed definition of proxy signature security. Since a secure proxy signature scheme assumes the existence of a secure signature scheme; we start from the security of standard signatures. We combine the standard unforgeability definition with the question of signature ownership in the multi-user setting, thereby providing a unified security definition. This is followed by a security definition of proxy signature. Discussion on its relation to the definition of [7] is in §4. We show that our proposed definition is stronger than the previous definition.
In §5 we revisit the construction of secure proxy signature scheme based on the delegation-by-certificate approach. However, the formal security argument reducing security of proxy signature to that of standard signature encounters an obstacle. It turns out that the task a proxy signature adversary faces cannot necessarily be reduced to the security of standard signature, even in the multi-user setting. We conclude with an open question: can it be the case that the new security goal is not implied by the existing definition of security for standard signature. Notation. In the exposition the symbols wrnt, σ and pσ denote the output of a signing algorithm S. The symbol pΣ is used to denote a proxy signature which may contain extra information besides a signature pσ, that is pΣ = pσ aux for some auxiliary information aux. As usual denotes concatenation.

A case for a stronger definition
The most natural construction of a proxy signature is through delegation-bycertificate. An entity, say Alice, delegates a proxy signer, say Bob, by providing a warrant together with a signature on the warrant. However, the naive construction does not distinguish a proxy signature and a regular signature leading to some kind of mismatch attacks [7, §4]. There is a simple solution: a standard signature on a message M is generated by first prepending 11 to M and signing this encoded message. A warrant, on the other hand, is generated by first prepending the string 00 to the warrant message to get wrnt, while a proxy signature on M is a signature on the message 01 M .
However, there still remains a malleability issue as observed in [7, §4]. An adversary can designate an honest entity, say Bob, as a proxy signer for Alice. Given a delegation-by-certificate proxy signature of Bob on behalf of Alice, the adversary can substitute the warrant from Alice to Bob with a warrant from, say Mallory to Bob. The result is a valid proxy signature of Bob on behalf of Mallory, even though Bob never issued such a proxy signature. According to [7], the simple solution is to append Alice's public key in the message to be signed by the proxy signer Bob: instead of signing 01 M , Bob now signs 01 pk A M , where pk A is Alice's public key. With these modifications, [7] arrives at the following delegation-by-certificate construction: [7,Construction 4.1]. Let DS = (G, K, S, V) be a signature scheme (Definition of DS from [7] is reproduced in Appendix A). The corresponding delegation-by-certificate proxy signature scheme is defined by the following set of algorithms PS[DS] = (G 1 , K 1 , S 1 , V 1 , (D, P), PS, PV, ID).
• The parameter-and key-generation algorithms are those of DS : G 1 = G, K 1 = K. • A standard signature for message M is obtained by prepending 11 to the message and signing the result using S, i.e. S 1 (sk, M ) = S(sk, 11 M ). • Verification of a signature σ for message M is done by computing V 1 (pk, M, σ) = V(pk, 11 M, σ). • User i, in order to designate user j = i as a proxy signer for message space ω, simply sends to j the description ω of the message space, together with a warrant wrnt = S(sk i , 00 j pk j ω) (i.e., a signature on the message 00 j pk j ω, under the secret key of user i). The corresponding proxy signing key of user j is psk = (sk j , pk i , j pk j ω, wrnt). • User i, in order to designate itself as proxy signer for message space ω, runs K to obtain (pk i , sk i ), and creates a warrant wrnt = S(sk i , 00 i pk i ω). The corresponding self-delegated proxy signing key of user i is psk = (sk i , pk i , i pk i ω, wrnt).
• A proxy signature by user j on behalf of user i on message M ∈ ω using proxy signing key (sk, pk i , j pk ω, wrnt) 1 , contains the identity j of the proxy signer, the message space description ω, the public key pk of the proxy signer, the warrant wrnt (a signature for 00 j pk ω under sk i ) and a signature for 01 pk i M under sk. Formally, PS ((sk, pk i , j pk ω, wrnt), M ) = (j, ω, pk, wrnt, S(sk, 01 pk i M )) .
To formulate a strong security definition, Boldyreva et al. [7] claimed to have considered an extreme scenario where only one user (denoted as user 1) is honest. The paper summarizes the goal of an adversary against the proxy signature scheme as follows.
G1 forgery of a standard signature: signature σ produced by the adversary is valid under the public key of user 1; G2 forgery of a proxy signature by user 1 on behalf of user j = 1: the proxy signature belongs to user j even though user 1 was not designated by user j, or if there was a designation then the message was not queried to the corresponding proxy signing oracle; G3 forgery of a proxy signature by user 1 on behalf of user 1: the proxy signature belongs to user 1 even though user 1 did not self-designate, or if there was such a designation then the message was not queried to the corresponding proxy signing oracle; G4 forgery of a proxy signature of user i = 1 on behalf of user 1: user i was not designated by user 1 to sign M . Based on these goals a formal security model [7,Definition 3.2] is proposed and shown that the delegation-by-certificate [7,Construction 4.1] is secure in that model. Essentially, if an adversary can achieve any of the above goals then that amounts to forgery in the underlying signature scheme. An Attack Scenario. We have already recalled how [7] addressed the problem of malleability in proxy signature by including the designator's public key as part of the message signed by the proxy signer (see [7,Construction 4.1] reproduced above). However, this measure does not necessarily prevent forgery by exploiting malleability of a proxy signature by user 1 on behalf of user i as we show next. In this attack, the adversary is given a proxy signature pΣ = (wrnt, σ) by proxy signer user 1 on behalf of designator user i. The adversary can generate a valid proxy signature pΣ = (wrnt , σ) for the same message where wrnt is the warrant from some user o created by the adversary with public key same as that of user i. Thus in this attack scenario the adversary can achieve goal G2 described above.
The attack uses the Elliptic Curve Digital Signature (ECDSA) as standardized in FIPS186-4 [23, §6]. See Appendix B.1 for a description of the ECDSA signing and verification algorithm. In [23] the domain parameters for ECDSA are (q, F R, a, b, {, domain parameter seed}, G, n, h) where q, F R correspond to the underlying field and (a, b) describe the elliptic curve. A (private-public) key pair is defined as (d, Q) for d ∈ [1, n−1] and Q = dG for a generating point G on the elliptic curve as specified in the standard. This is in line with other standards such as [2, §2.3.5], where a point on the curve is represented as an "OCTET STRING", or [22], where the (private-public) key pairs are also an integer d and an elliptic curve point Q, or [8, §3.2]. The important point to note is that, as per these standards, a public key is simply an element of an elliptic curve group. Let the public key of user 1 be pk 1 , where pk 1 = sk 1 G 1 . The associated parameters were generated by user 1 as recommended in FIPS186-4 [23], with parameters (q 1 , F R 1 , a 1 , b 1 , {, domain parameter seed 1 }, G 1 , n 1 , h 1 ).
User i has public key pk i where pk i = sk i G i with associated parameters Suppose user i designates user 1 via warrant wrnt i→1 on message space ω and user 1 issues a proxy signature on some m ∈ ω on behalf of user i as pΣ = (1, ω, pk 1 , wrnt i→1 , σ). According to [7,Construction 4.1], proxy signature verification is To mount the attack, the adversary creates a warrant wrnt o→1 on behalf of user o = i under a message space ω with M ∈ ω and with public key pk o = pk i . Then by substituting the warrant issued by user i with the one issued by user o, the adversary creates a new proxy signature on M as pΣ = (1, ω , pk 1 , wrnt o→1 , σ). It is easy to verify that pΣ will be accepted as a valid proxy signature issued by user 1 on behalf of user o, even though user 1 was not designated by user o thereby defeating Goal G2 outlined above.
Note that in the security model of [7] there is only one honest user, namely, user 1. Thus assuming user i to be malicious, user o could obtain the private key corresponding to pk o from user i and create the warrant wrnt o→1 . This is a valid attack since [7] does not explicitly require that different users have different public keys, in fact the adversary is implicitly allowed to register any (valid) key. However, let's additionally assume that the adversary has no access to the private information of user i i.e., both the designator and proxy signer are deemed to be honest. In other words, we consider the multi-user setting. The above attack can nevertheless be mounted by crafting a suitable certificate.
As per FIPS186-4 [23], a user is allowed to generate public parameters of her choice. To mount the attack user o creates a malicious certificate with public key pk o = pk i and parameters identical to those used by user i except for the generating point G i . Given the parameters of user i, user o selects the same curve but with generating point G o = sk −1 o pk i where sk −1 o is a random integer modulo n i . This is possible, see [23, §6.1.1], as it is not mandatory to exhibit a proof that G is generated at random. In Appendix B.2.2 we have described the above attack on a concrete toy example. Note that this attack is closely related to but different from DSKS attacks on ECDSA reported in the literature (see, for example, [17, §2.2

.4]).
A Second Scenario. We discuss another plausible attack scenario which is not covered by any of the goals G1-G4 in [7]. Suppose an honest user 1 located in the Far East wants to enter an auction taking place in Europe. To avoid late night bidding user 1 grants a warrant to a proxy (user i) to enter the auction on behalf of user 1. Suppose user i makes a winning bid. A little later an entity (user o) located in the west coast of America learns about the results and wants to claim the item auctioned.
Let the warrant issued by user 1 to user i be denoted by wrnt 1→i on the message space ω. As per [7,Construction 4.1], the proxy signature on message M -the bid by user i on user 1's behalf -is pΣ = (i, ω, pk i , wrnt 1→i , pσ) where pσ = S(sk i , 01 pk 1 M ).
The proxy verification algorithm takes as input the designator's public key pk 1 , the message M and a proxy signature. Now user o crafts a certificate with public key pk o = pk 1 and private key sk o as discussed in the attack scenario above; then generates a new warrant wrnt o→i on message space ω designating user i as proxy signer. With that pΣ = (i, ω, pk i , wrnt o→i , pσ) , where as before pσ = S(sk i , 01 pk 1 M ), is a 'new' proxy signature on the same bid M that verifies under the public key pk o of user o.
Some similarities notwithstanding, there is a fundamental difference between the two attack scenarios. In the first case, the honest user is the proxy signer whereas in the second the honest user is the designator. We illustrate this point in Figure 1. Figure 1(a) depicts the forgery attack in the first scenario where pΣ is a proxy signature of user o even though honest user 1 had not issued such signature (or perhaps not even received authorization to sign on user o's behalf); (b) is the ownership attack in the second scenario (and its generalization is in (c)). Given a proxy signature that belongs to honest designator user 1 and using the inherent malleability of pΣ, user o is able to generate a valid proxy signature pΣ . Clearly this is not a forgery of the honest designator user 1. Since there is no assumption about the honesty of proxy signer user i, neither can this be construed as a forgery of user i. Since [7, Definition 3.2] considers only proxy signature forgery and not ownership, attacks depicted in Figure 1(b) and (c) are not covered in that security definition. The above discussion suggests that the security definition of proxy signature needs to be augmented: not only should an adversary be unable to forge signatures, but she should also be unable to misappropriate signatures of honest users, whether signed via a proxy or not. The original security model of digital signature [13,14], formulated as existential unforgeability under chosen message attack (EUF-CMA), considers a single signer. The security of signature schemes in the multi-user setting has been further investigated by several researchers (for example, [21,24,15]). These works demonstrate the need to formalize the notion of signature ownership as part of the security definition in the multi-user setting. Pornin and Stern [24], in particular, proposed three different notions of ownership of signature. We recall their definition of universal exclusive ownership from [24], which is strongest of the three.
Definition 3.1 (Universal exclusive ownership). [24, Definition 3] Given a public key pk and t pairs (M i , σ i ) of message-signature that verify under the public key pk, it is infeasible to create a public key pk = pk and a matching private key sk such that at least one message-signature pair (M i , σ ), with σ = σ i for some 1 ≤ i ≤ t verifies under pk . Further, there is no restriction that M i = M i .

3.1.
Signature security: A combined definition. Rather than considering multiple security aspects separately (existential unforgeability versus universal exclusive ownership; single user versus multi-user setting) we prefer to use a single security definition that encompasses all the above aspects. This will allow us to focus only on the relation between the new primitives and definitions we state later in the context of proxy signature and to simplify security arguments.
Definition 3.2 (EU-UEO-CMA). We say that a signature scheme in the multiuser setting is existentially unforgeable providing universal exclusive ownership under adaptive chosen message key attack EU-UEO-CMA if an adversary who can adaptively request t public keys with associated certificates, for each is given a signing oracle that can adaptively provide at most t i signatures for the corresponding cert, and adaptively request private keys corresponding to cert, cannot output (cert i , M, σ) or [(cert i , M, σ), (cert o , M , σ)] such that the triplet (cert i , M, σ) is a valid signature under cert i , the certificate cert i is requested by the adversary, the adversary did not query for the corresponding private key and one of the following holds: 1. either the message M was not queried to the oracle with cert i ; 2. or (M, σ) is a response from the oracle with cert i and (M , σ) is a valid signature under cert o (here cert o = cert i ).
Note that in our definition we use a certificate cert instead of a public key. The original UEO definition deals only with public keys implicitly assuming one certificate per public key. Thus a relevant issue is whether an honest user can possess two certificates with the same public key. If UEO is defined via certificates, then there is a trivial UEO attack if we allow the same public key under, say, two different certificates. In this work we will assume honest users generate novel key pairs for every new certificate. The certificates may share public parameters such as underlying elliptic curve or field, as well as information such as the identifier of a party. In other words, there is a one-to-one correspondence between public keys and the certificates of honest users.
It is straightforward to show that EU-UEO-CMA security is implied by EU-CMA and UEO security. For the sake of completeness we state this in the following theorem (see Appendix C.1 for the proof). Theorem 3.3. Let DS = (G, K, S, V) be a signature scheme that is both EU-CMA and UEO secure. Then it is also EU-UEO-CMA secure.

3.2.
Proxy signature. In the following, rather than talking about users we will talk about certificates and assume that each certificate is unique; instead of saying that user i designates user j to sign certain message we say that a certificate cert i designates another certificate cert j to sign messages. The entity owning the certificate cert j is responsible for maintaining the corresponding private key. • (G, K, S, V) is a signature scheme; • (D, P) is a pair of interactive randomized algorithms forming the (two-party) proxy-designation protocol. The input to each algorithm includes two certificates cert i , cert j for the designator i and the proxy signer j, respectively. D also takes as input the secret key sk certi corresponding to public key listed in cert i , and a message space descriptor ω for which user i utilizing cert i wants to delegate signing rights to user j owning cert j . P also takes as input the secret key sk certj corresponding to the public key listed in cert j . As a result of the interaction, the expected local output of P is spk, a proxy signing key that user j uses to produce proxy signature on behalf of user i, for messages in ω. D has no local output. We write • PV is the deterministic proxy verification algorithm. It takes input a chain cert i w → cert j a message M ∈ {0, 1} * , a proxy signature pΣ and auxiliary input aux, and outputs 0 or 1. In the latter case, we say that pΣ is a valid proxy signature for M relative to cert i w → cert j .
Correctness. We require that (i) the signature scheme is correct and (ii) for any message space ω ⊆ {0, 1} * and for all users i, j ∈ N, if skp is a proxy signing key of user j on behalf of user i for message space ω, i.e., then for every M ∈ ω, with probability one For notational simplicity, we will write cert i →cert j in place of cert i w → cert j when w is clear from the context. Observe that, unlike [7], our definition does not have the identification algorithm. We have dispensed with it as it seems the algorithm does not have any role in the adversary's security goal.
Remark 1. Unlike the definition in [7], the output of PS is a (proxy) signature along with some auxiliary information. Similarly, the input to PV is a (proxy) signature along with auxiliary input. This, however, does not modify the algorithms in any fundamental way. Indeed by redefining pΣ as the concatenation of pΣ with aux the definition can dispense with aux. However, for clarity of presentation we prefer this separation. For the particular construction [7, Construction 4.1] the original notation is pΣ = (j, ω, pk, wrnt, S(sk, 01 pk i M )) whereas with our notation, aux = (j, ω, pk, wrnt), pΣ = S(sk, 01 pk i M ).
In our opinion, this division is natural since multiple proxy signatures can share the values in aux. Furthermore, the mapping between the two notation is a bijection thus previous security arguments apply with the new notation as well.
3.3. Security model. Our model distinguishes between users/entities and certificates. A user may own more than one certificate but for an honest user there is a one-to-one correspondence between each public key and certificate. Users that are not adversary controlled follow the protocol specifications. When interacting with other entities, the interaction is based on information provided in a certificate. If two distinct entities possess and use identical certificates the related responsibility lies with the issuing authority.
Honest users interact with valid certificates only -such as those meeting the criteria in [9,28]. Honest users own certificates for which they generate public parameters and keys according to specifications and it is possible that parameters except public keys are shared across multiple certificates.
The adversary can also create certificates, but is not obliged to follow specifications when creating public parameters or keys. However, to interact with any user the adversary must have a valid certificate. Any adversary-created certificate is called adversary controlled or adversarial. Due to various reasons users may expose their private keys to adversaries. Such action is allowed in our model and the corresponding certificates are labeled discredited. Together, adversary controlled and discredited certificates are called compromised. Our model implies no forgery guarantee for compromised certificates, but they play an important role in the context of signature ownership.
3.3.1. Adversarial queries. Here we describe the adversarial environment. The adversarial queries are a generalization of the queries allowed in [7], which had a single honest user, here the number of honest users is polynomially bounded (in the security parameter κ). For each honest user the adversary is allowed similar type of queries as in [7].
Let PS = (G, K, S, V, (D, P), PS, PV) be the proxy signature scheme, A is an adversary against PS who runs in time polynomial in κ ∈ N. We associate to PS, A and κ an experiment Exp ps−uf PS,A (κ). A counter HU (honest users) is set to one. A can make the following queries, in any order.
new i: A is given access to a new honest user indexed by i = HU and HU is increased by one. Associated with the honest user there is a (per user) counter c i set initially to zero (c i will index the certificates generated for user i). The experiment initializes empty lists DU i , PU i , CS i and CC i . The set DU i stores the certificates designated by the user i (together with the message spaces for which they are designated and with which certificate the designation was done). The set PU i keeps the designations for which the user can proxy sign messages along with signing keys; CS i keeps track of the set of messages (ω) for which the adversary can produce proxy signature by user i using compromised proxy signing keys. And lastly CC i keeps track of the certificates for which the adversary obtained the corresponding private key. new (cert i , info, i): If info does not contain domain parameters, then these parameters params are generated by running G on input 1 κ . A new key pair is generated via (sk ci i , pk ci i ) ← K(params) Then a new certificate cert ci i incorporating params, pk ci i is generated for user i; the counter c i is incremented by one. The certificate becomes available to all users; the private key corresponding to the public key listed in the certificate is available only to user i. In particular the adversary does not know the corresponding private key. We say user i owns the certificate cert ci i . Any other information contained in info is included in fields allowed in cert ci i . For example, the adversary can require that a certain id string (such as email address) associated with entity i be used in the generated certificate. register cert o : A can request to register a certificate cert o that becomes available to all users. The certificate is adversary controlled (i.e. compromised). We say that PS is a secure proxy signature scheme if the function Adv ps−uf PS,A (·) is negligible for all adversaries A of time complexity polynomial in the security parameter κ.  [21,Definition 4]. Note that the adversary is considered successful even when s/he explicitly requests a signature for an uncorrupted certificate and then creates a different chain/certificate under which the same signature verifies.

Relation to previous definition
As with any new definition, a natural question is how the proposed definition compares with the existing one. The following theorem shows that our proxy signature definition is no weaker than the one in [7]. Proof. Given an adversary A in the sense of [7, Definition 3.2] we construct an algorithm R that transforms A into an adversary M in the sense of §3.3. In the remainder of the argument aux is empty and omitted from the exposition.
The algorithm R is initiated with its inputs and starts by issuing new 1 and new (cert 1 , info, 1) where info is empty; as a result cert 1 1 = cert 1 . Let pk 1 be the resulting public key. The algorithm A is initiated with pk 1 and R responds to queries by A in the following way: registers pk i : R issues register cert o with public key pk i (we assume a signature scheme that incorporates validation procedures that allow for valid certificate generation); 1 designates i: R issues cert 1 1 designates cert i ; i designates 1: R requests that cert i designates cert 1 1 ; 1 designates 1: R issue new cert c1 1 with public key pk c1 1 ; increments c 1 and requests that cert 1 1 designates cert c1 1 . exposure of self delegation: for the lth proxy signing key, R repeats the query asking for the lth proxy signing key of user 1. We note that if the proxy signing key is simply the key in the lth certificate of user 1 the certificate is considered compromised but as far as the environment of A is concerned the existence or non-existence of the certificate is independent from obtaining the proxy signing key; the response is forwarded to A; standard signature by 1: R queries O S (cert 1 1 , ·) and forwards the response to A; proxy signature of user 1 on behalf of user i: using the lth proxy signing key -R queries O PS (cert i → cert 1 1 , ·) with message and information provided in A's query; e.g., cert i has the public key provided by A, which could in particular be a public key generated for user 1 during self delegations, and the remaining information such as the message is included in the oracle query. The response is forwarded to A; The simulation of A's environment is therefore perfect, and depending on A's output R outputs , ·), then R outputs (cert c1 1 → cert 1 1 , M, pΣ), here cert c1 1 has the public key corresponding to sk u ; the output is a valid proxy signature forgery and R is successful; forgery of a proxy signature on behalf of 1 by i = 1 where 1 did not designate i: if A outputs (M, pΣ, pk 1 ), where 1. PV(pk 1 , M, pΣ) = 1 and 2. for each ω such that (ID(pΣ), ω) ∈ DU 1 it holds that M ∈ ω, then R outputs (cert 1 1 → cert i , M, pσ), where cert i contains the public key corresponding to the identity ID(pΣ), which is a valid proxy signature forgery and R is successful. no success: in all other cases R terminates unsuccessfully.
So if A is successful then R is also successful; equivalently if the proxy signature is secure in the sense of §3.3 it is secure in the sense of [7, Definition 3.2].
Our proposed security definition of proxy signature also encompasses signature security definitions from [24] (see also [21, §2.2]). In particular, given a messagesignature pair under the public key of an honest user, the definition implies that there is no efficient algorithm to create a new public-private key pair under which the same message-signature pair will validate. This feature of preventing public key substitution attack means our definition addresses signature ownership issue for both signature and proxy signature setting in a unified way and we get the following result. Proof. As with the argument for Theorem 4.1, we proceed by showing that the contrapositive holds. In particular, an EU-UEO adversary A against the signature via a reduction R can be transformed into an adversary against the proxy signature. The algorithm R is initiated with its inputs, access to A and starts by issuing new i and new (cert i , info, i) for i = 1 . . . n where info is empty for each index i and n is the number of public keys A takes as input. The algorithm A is initiated and R responds to ith certificate query by returning the ith certificate. For An immediate corollary using Theorem 3.3 is that the existence of a proxy signature scheme secure in the sense of §3.3 implies the existence of a signature scheme that is UEO-secure.
Finally, the following claim establishes that our security definition is stronger that of [7]. The claim is established through a delegation-by-certificate proxy signature construction. Note that we have already shown an attack on [7, Construction 4.1] in their own security model. However, by replacing the public key used in [7, Construction 4.1] by the corresponding certificate one can easily show that this construction is secure in the sense of [7, Definition 3.2]. This modification is easy to achieve because we have assumed that there is a one-to-one correspondence between public keys and certificates for honest users.
Given this generic construction of a proxy signature we now build a separating example, which closely follows [15, Example 1] that we recall first.
Let DS = (G, K, S, V) be any EU-CMA secure signature scheme. Define DS = (G , K , S , V ) as the cheat variant of DS.
1. G is a randomized algorithm that on input 1 κ outputs a set of domain parameters params by running G. The algorithm may output some additional information I that can be used to verify some properties of the output.

K is a randomized algorithm which on input a set of domain parameters
params outputs with overwhelming probability a (private-public) key pair (sk, pk) associated with domain parameters params by running K. However, with negligible probability K outputs a special key pair (Cheat, Key) valid for all domain parameters; 3. S upon called with key Key outputs a special signature ValidOnlyForCheat, in all other cases S is executed; 4. V first checks if the verification is against the key Cheat. In this case the signature is accepted without any further checks. In all other cases, V is run and its output returned. Since the key generation algorithm outputs Cheat with a negligible probability, the signature scheme DS is EU-CMA secure. Using [7, Construction 4.1] we obtain a proxy signature scheme secure in the sense of [7,Definition 3.2]. However, this scheme will be insecure in the new definition of §3.3. In particular an adversary can easily achieve Goal 4(a) (and Goal 4(b)) of §3.3.2 as described below.
Following [7,Construction 4.1], we can define a proxy signature scheme as follows: • G returns the output of G; • K is a randomized algorithm which on input a set of domain parameters params outputs with overwhelming probability a (private-public) key pair (sk, pk) associated with domain parameters params by running K. However, with negligible probability K outputs one of the special key pairs (Cheat s , Key s ) and (Cheat p , Key p ) valid for all domain parameters. The former is used for ordinary signature and the latter for proxy signature. • S upon called with key Key s outputs a special signature 11ValidOnlyFor Cheat s , upon called with key Key p outputs a special signature 11ValidOnly ForCheat p , in all other cases S is executed; • V first checks if the verification is against the key Cheat s or Cheat p then the signature is accepted without any further checks. In all other case V is run and its output returned. Cheat p ) in the warrant issuing step. When signing with Cheat s (resp. Cheat p ), the output will be 10ValidOnlyForCheat s (resp. 10ValidOnlyForCheat p ). • PV : if the verification key is Key s and the proxy key is Key p then accept the proxy signature without further verifications, else run PV of [7, Construction 4.1] and return its output. The above scheme is identical to [7,Construction 4.1] except with negligible probability of generating either of the cheat keys. Hence the construction is secure in the sense of [7]. On the other hand given any proxy signature of user 1, the adversary can succeed in achieving Goal 4(a) by setting the keys Cheat s and Cheat p for the designator and proxy respectively and claim any proxy signature belonging to this set of users. The Goal 4(b) can also be achieved in a similar fashion.

Revisiting security of delegation-by-certificate construction
With the appropriate modification in the security definition as discussed above, one may expect to finally establish that delegation-by-certificate leads to a provably secure proxy signature construction. We discuss the security of such a generic construction which is an extension of [7, Construction 4.1]. 5.1. Proxy signature construction. Let DS = (G, K, S, V) be a signature scheme. We define the corresponding delegation-by-certificate proxy signature scheme as follows PS[DS] = (G p , K p , S p , V p , , PS, PV). The construction assumes the existence of a cryptographic hash function H with appropriate range and domain.
• The parameter-and key-generation algorithms are those of DS: G p = G, K p = K. The resulting public parameters and public keys are encoded in a certificate cert. • Verification of a signature for message M under information provided by cert is done by computing V p (pk cert , M, σ) = V(pk cert , H(cert) M, σ). • Proxy delegation (D, P) works as follows. User i with certificate cert ci , in order to designate user j with certificate cert cj = cert ci as a proxy signer for messages in message space ω, sends to j the description ω of the message space, together with a warrant which is a signature on the message H(cert ci ) H(cert ci cert cj ) H(cert cj ) ω under the secret key corresponding to cert ci . In other words, The corresponding proxy signing key of user j is skp = (sk certc j , cert ci cert cj ω, wrnt). User i using certificate cert ci is not allowed to designate the same certificate cert ci -in line with [7] -avoiding circular self-delegations.

5.2.
On security. We want to formally establish that the above construction is secure in the security model of §3.3 provided the underlying signature scheme is EU-UEO-CMA-secure (Definition 3.2). The natural approach is to give a reduction. In other words, show that if a polynomial time adversary against the proxy signature scheme can achieve one of the four goals as formulated in §3.3.2 with some nonnegligible advantage then one can construct a polynomial time adversary which breaks the EU-UEO-CMA security of the underlying signature scheme with some non-negligible advantage. Such a reductionist argument turns out to be quite straightforward when there is a (proxy) signature forgery. When the goal of the (proxy) signature adversary is one of the Goals (1), (2), (3) of §3.3.2, the reduction can easily produce a forgery for the underlying signature scheme. We provide a sketch towards such a reduction in Appendix C.2.
However, things take a somewhat unexpected turn when one considers security in terms of (proxy) signature ownership, as defined in Goal (4) of §3.3.2. As an illustration, consider Goal 4(a) from §3.3.2. In this case the proxy signature adversary is considered successful if the following event occurs: The adversary returns the following: (cert ci i → cert In other words, the proxy signature adversary breaks the "ownership" property of the underlying proxy-signature scheme. In such an eventuality we expect to show that the signature adversary can break the UEO-security of the underlying signature scheme. However, it appears that to formally establish such a claim we need either an additional assumption on the proxy signer or to change the exclusive ownership definition for signature schemes.
Modifying the assumption: One way to circumvent the problem is to additionally assume that one of the two proxy certificates {cert cj j , cert c j j } is not compromised. We elaborated this approach in the reduction argument of Appendix C.2. In that case the reduction R returns the UEO forgery Thus, from the perspective of an honest designator, for the desired reductionist security claim to hold s/he needs the additional assumption that the proxy is honest. Arguably such a restriction is extremely difficult to ensure in the real world. Furthermore, any natural security definition of proxy signature needs to consider scenarios where a party tries to produce a proxy signature even when not authorized to do so. Hence we do not think that assuming honest proxy is a realistic assumption.
Modifying the definition: The other alternative seems to be a modification in the corresponding definition of exclusive ownership for signature schemes. If both the proxy signers in the above mentioned scenario of Goal 4(a) are controlled by the adversary then in terms of the underlying signature scheme the adversarial goal is the following: given a signature scheme (G, K, S, V), produce two public keys (pk 1 , pk 2 ), two messages (m 1 , m 2 ) that when signed with the two public keys (pk 1 and pk 2 ) will result in the same signature (σ). Obviously this goal is different from the adversarial goal in exclusive universal ownership definition [24] where the adversary is given one of the public keys.
In the UEO-security game, the target public key and associated parameters are generated as specified by the signature scheme whereas in the above scenario the adversary may craft parameters and both the public keys in a malicious fashion. In [27] the signature scheme includes an algorithm that validates domain parameters along with standard verification of signature. However, as noted in §2, validating public parameters does not prevent dishonest users from claiming (proxy) signature of honest users. Thus adding a parameter verification algorithm as suggested in [27] does not necessarily bridge the gap.
In fact if we restrict our attention to ordinary signature schemes then such problem looks somewhat artificial: an adversary who may not honestly follow parameter generation, key generation and signature generation, produces two public keys with associated public parameters, two (perhaps distinct) messages which result in the same signature that validates under two different public keys.
The work of Bohli, Röhrich and Steinwandt [15] does consider the case of malicious signers. In [15,Definition 3] they consider a single message-signature pair and two public keys generated by the adversary. Whereas the adversary's goal in the above reduction is to craft two public keys and two (distinct) messages that verify under the same signature. Both the problems are trivial for ECDSA [23] (see Appendix B.3 for an example of the latter). From the perspective of an honest user, her keys are not involved so no liability can be placed on the user. Thus there appears to be little practical motivation to modify the security definition of standard signature to incorporate the above attack scenario.
Remark 3. Instead of modifying either the signature security definition or the assumption about honest proxy, one may attempt to find a middle way. Suppose we only require that a single proxy is incorporated in Goal 4 of proxy signature security definition. In this scenario, both the designators delegate to the same proxy signer. The adversarial goal now would be to create one public key, two distinct messages, one signature such that the two messages verify under the same signature public key pairs. The problem sounds more restrictive than the previous case where the adversary can pick two distinct public keys. Nevertheless, reduction to UEO still seems unlikely due to the same issue: in UEO the adversary is given the target public keys whereas here the adversary crafts the public parameters and keys.
Remark 4. Independently, the issue of producing the private keys (or prove their possession) corresponding to public keys (called weak and strong goals in [15]) can be incorporated in all of the above problem variants. Nevertheless, the difference in the problem definition that lies in being given a public key and crafting a public key still remains. As already mentioned, there appears to be little motivation to consider adversarial actions that are not related to any public keys associated with honest users. The fact that the adversary may or may not produce the corresponding private key has little relevance to the practicality of these problems.
Perhaps a stronger requirement on the adversary than just a proof-of-possession of private keys may work: for example a proof that the adversary did indeed follow the protocol specifications of G and K, so that crafting public parameters and keys is equivalent to being given public keys. Unfortunately, for standardized, state-ofthe-art signature schemes like ECDSA such assumptions may well be false.
Various works [21,15,27,24] suggest that definition of signature security in the multi-user setting is not yet completely understood. Consequently, we may lack the "right" definition of security of signature in the multi-user setting. Given that proxy signature by definition requires a multi-user setting, it may well be the case that existing signature security definitions are not sufficient to craft an appropriate proxy signature security definition. In fact obtaining the right proxy signature definition may be as challenging as defining a secure signature in the multi-user setting. Furthermore, there is no guarantee that a secure signature scheme will be sufficient to obtain a secure proxy signature scheme. It is plausible to assume that, along with right definition of signature in a multi user setting, a necessary requirement for proxy signature would be a "right" definition of delegation of trust.

Acknowledgements
We thank the anonymous reviewers for their elaborate and insightful comments which helped us in improving the presentation as well as address some of the shortcomings.

Appendix A. Definitions
For completeness here we recall definition and security model of (proxy) signature from [7]. Note that we have slightly modified the standard signature definition by introducing certificate corresponding to a public key.
Definition A.1. [Signature scheme] For a security parameter κ a signature scheme is a tuple of algorithms (G, K, S, V) where 1. G is a randomized algorithm that on input 1 κ outputs a set of domain parameters params. The algorithm may output some additional information I that can be used to verify some properties of the output; 2. K is a randomized algorithm which on input a set of domain parameters params outputs a private-public key pair (sk, pk) associated with domain parameters params. The values (pk, params) can be unambiguously embedded in and extracted from a description called certificate and denoted by cert; the algorithm may output some additional information that can be used to verify that the parameters were honestly generated; 3. S is a randomized algorithm that on input a message M , a private key sk with associated certificate containing system parameters params and a public key pk, outputs a digital signature σ ∈ {0, 1} * ∪ ⊥; 4. V is a deterministic algorithm that on input a cert -a certificate incorporating params and a public key pk, a message M and a digital signature σ, outputs 1 or 0.
Signature correctness. A signature scheme is correct if for a certificate cert containing (pk, params), where sk and pk are associated with params, we have that V(cert, M, S(cert, sk, M )) = 1.
Definition A.2 (proxy signatures [7]). A proxy signature scheme is described by a tuple PS = (G, K, S, V, (D, P), PS, PV, ID), where the constituents are polynomial time algorithms, DS = (G, K, S, V) is a digital signature scheme, and • (D, P) is a pair of interactive randomized algorithms forming the (two-party) proxy-designation protocol. The input to each algorithm includes the public key pk i of the designator i, and the public key pk j of proxy signer. D also takes as input the secret key sk i corresponding to pk i , the identity j and a message space descriptor ω. P also takes as input the secret key sk j . As a result, the expected local output of P is a proxy signing key spk used to produce proxy signatures on behalf of user i for messages in ω. D has no local output. • PS is the (possibly) randomized proxy signing algorithm that takes as input a proxy signing key skp and a message M ∈ {0, 1} * , and outputs a proxy signature pΣ ∈ {0, 1} * ∪ {⊥}.
• PV is the deterministic proxy verification algorithm. It takes input a public key pk i , a message M ∈ {0, 1} * , a proxy signature pΣ and outputs 0 or 1. • ID is an identification algorithm that on input a valid proxy signature pΣ, outputs an identity or ⊥ in case of an error.
Correctness. For any message space ω ⊆ {0, 1} * and for all users i, j ∈ N, if skp is a proxy signing key of user j on behalf of user i for message space ω, then for every M ∈ ω, with probability one PV pk i , M, PS(skp, M ) = 1 and ID(PS(spk, M )) = j. Security Model. The adversarial environment in [7] involves a single honest user. Let PS = (G, K, S, V, (D, P), PS, PV) be a proxy signature scheme, A an adversary and κ ∈ N. Associated to PS, A and κ is an experiment Exp ps−uf PS,A (κ). Initially, system parameters are generated using G and a public-private key pair (sk 1 , pk 1 ) is generated for user 1 using K. Empty set DU and CS are created along with an empty array SD; here DU is the set of users designated by 1, CS is the set of users that designated user 1, and SD is the array that stores the self designated proxy signing keys and corresponding message spaces. The value n is initialized to one.
Adversary A, given pk 1 , can make the following queries (in any order) polynomially in κ number of times.
i register pk i : A registers a key pk i for user i = n + 1. The key is stored and the counter n is incremented. An empty array skp i is created that will store the proxy signing keys of user 1 on behalf of user i, along with the message space descriptor. i designates 1: On A's choice of message space ω for some i ≥ 2 the adversary interacts with 1 that executes D(pk 1 , sk 1 , i, pk i , ω). In the interaction A plays the role of user i running the appropriate P. After a successful run [i, ω] is appended to DU i . 1 designates i: A interacts with user 1, whereby i runs P(pk i , sk i , pk 1 ), for some i ≥ 2. In the interaction A plays the role of user i for a message space ω of the adversary's choice. If skp is the resulting proxy signing key, then entry [skp, ω] is appended to the array spk i . A does not have direct access to spk i . 1 designates 1: A interacts with user 1, whereby 1 designates itself. As a result A is given the transcript output and [spk, ω] is appended to spk 1 , where spk is the resulting proxy signing key and ω is the message space description. exposure of user 1's lth proxy signing key during self delegation: A can request the self delegation proxy signing key stored at spk 1 [l]. In this case the corresponding key is given to A and CS is set to CS ∪ ω. If no key exists at spk 1 [l], ⊥ is returned to A. standard signature by 1: A can query oracle O S (pk 1 , M ) with a message M and obtain a standard signature σ for M by user 1. proxy signature of user 1 on behalf of user i: (using the lth proxy signing key) A can make a query (i, l, M ). As a result A obtains the proxy signature on message M using proxy signing key stored at spk i [l], assuming there is such key and M belongs the corresponding message space ω. Otherwise the query is invalid and the response is ⊥. We say that PS is a secure proxy signature scheme if the function Adv ps−uf PS,A (·) is negligible for all adversaries A of time complexity polynomial in the security parameter κ. and our attack on proxy signature. These examples are generated using the SAGE library [29].
B.2.1. DSKS attack. For the same message-signature pair, we discuss two variants of the DSKS attack. In DSKS 1 the attacker selects a new generating point but uses the same elliptic curve as the honest signer. In DSKS 2, the attacker selects a new elliptic curve. See Appendix B.3 for details on parameter generation, signing as well as verification of ECDSA. One can also give examples of attacks whereby the underlying finite field is modified but that adds little insight beyond the two attacks and hence is not included.
Suppose the following is a signature generated by an honest user. Honest signer 1:

DSKS 2:
In this scenario, the attacker selects a new elliptic curve E 2 of order ≈ q = 3001, such that E 2 has a point with x coordinate 524. Using k 2 = 867, lifting signature value r = 524 to a curve point R = (524 : 111 : 1) and following Steps (5) to (9) Step 6 (vi) Since Z = R then it is not the point at infinity and r = int(x z ) mod n validating the signature. Note that the adversary not only produces the signature, s/he also has the private key corresponding to a public key. The attack can be modified to accommodate different public parameters as long as the x coordinate of the point R is fixed. Proof. In the EU-UEO-CMA security game there are more than one public keys from which an adversary may choose a target public key. The argument is a standard reduction with tightness loss of 1 n where n is the number of certificates the EU-UEO-UMA adversary is allowed to request.
Given a certificate cert target , a corresponding signing oracle and access to an adversary that EU-UEO-CMA breaks the signature scheme we construct the reduction algorithm R. Using K, the algorithm R generates n − 1 certificates, and then randomly orders the collection of generated certificates and the input certificate cert target . After these preparations R initiates the EU-UEO-CMA adversary A. When A requests the kth certificate R responds with the kth certificate in its list. When A queries the signing oracle with cert target the algorithm R queries its own signing oracle with the same message and forwards the answer to A. When A queries a signing oracle for one of the remaining n − 1 certificates R faithfully creates a signature and submits the result to A. When A requests a private key, the algorithm R responds faithfully unless the key corresponds to cert target in which case R aborts with failure.
Suppose We will attempt to show that above construction is secure in the sense of §3.3 assuming DS = (G, K, S, V) is a simultaneously UEO-and EU-CMA secure signature scheme. By Theorem 3.3 it suffices to assume that the signature is EU-UEO-CMA secure. The argument requires the construction of a reduction R that given access to a proxy signature adversary A breaks the EU-UEO-CMA security of the signature scheme. The algorithm R initiates A and responds to A's queries as follows: cj j ] is appended to PU i . As A does not have access to the first entry of PU j the simulation is perfect; exposure of user i's lth proxy signing key: if it exists, R queries for the signing key corresponding to the public key in the lth entry of PU i and responds to the query faithfully, else the query is ignored; exposure of certificate cert ci i owned by user i: if it exists, R queries for the signing key corresponding to the public key in the lth entry of PU i and responds to the query faithfully, else the query is ignored; standard signature for certificate cert ci i : R queries the corresponding oracle with the same message and forwards the response to A;