Multi‐designated verifiers signature schemes with threshold verifiability: generic pattern and a concrete scheme in the standard model

IET Information SecurityVolume 13, Issue 5 p. 459-468 Research ArticleFree Access Multi-designated verifiers signature schemes with threshold verifiability: generic pattern and a concrete scheme in the standard model Parvin Rastegari, Corresponding Author Parvin Rastegari parvin.rastegari@ec.iut.ac.ir Department of Electrical and Computer Engineering, Isfahan University of Technology, Isfahan, 84156-83111 IranSearch for more papers by this authorMohammad Dakhilalian, Mohammad Dakhilalian Department of Electrical and Computer Engineering, Isfahan University of Technology, Isfahan, 84156-83111 IranSearch for more papers by this authorMehdi Berenjkoub, Mehdi Berenjkoub Department of Electrical and Computer Engineering, Isfahan University of Technology, Isfahan, 84156-83111 IranSearch for more papers by this authorWilly Susilo, Willy Susilo Institute of Cybersecurity and Cryptology, School of Computing and Information Technology, University of Wollongong, Wollongong, NSW, 2522 AustraliaSearch for more papers by this author Parvin Rastegari, Corresponding Author Parvin Rastegari parvin.rastegari@ec.iut.ac.ir Department of Electrical and Computer Engineering, Isfahan University of Technology, Isfahan, 84156-83111 IranSearch for more papers by this authorMohammad Dakhilalian, Mohammad Dakhilalian Department of Electrical and Computer Engineering, Isfahan University of Technology, Isfahan, 84156-83111 IranSearch for more papers by this authorMehdi Berenjkoub, Mehdi Berenjkoub Department of Electrical and Computer Engineering, Isfahan University of Technology, Isfahan, 84156-83111 IranSearch for more papers by this authorWilly Susilo, Willy Susilo Institute of Cybersecurity and Cryptology, School of Computing and Information Technology, University of Wollongong, Wollongong, NSW, 2522 AustraliaSearch for more papers by this author First published: 01 September 2019 https://doi.org/10.1049/iet-ifs.2018.5063Citations: 3AboutSectionsPDF ToolsRequest permissionExport citationAdd to favoritesTrack citation ShareShare Give accessShare full text accessShare full-text accessPlease review our Terms and Conditions of Use and check box below to share full-text version of article.I have read and accept the Wiley Online Library Terms and Conditions of UseShareable LinkUse the link below to share a full-text version of this article with your friends and colleagues. Learn more.Copy URL Share a linkShare onFacebookTwitterLinkedInRedditWechat Abstract In a designated verifier signature (DVS) scheme, the validity of the signature can only be checked by a designated entity chosen by the signer. Furthermore, the designated entity cannot convince a third party that the signature is generated by the signer. A multi-designated verifiers signature (MDVS) scheme is an extension of a DVS which includes multiple designated verifiers. To the best of the authors’ knowledge, there are two existing patterns for an MDVS scheme. In the first pattern, every verifier of the set of designated verifiers can check the validity of the signature independently. In the second pattern, the cooperation of all designated verifiers is required for checking the validity of the signature. In this study, the authors propose a generic new pattern for an MDVS scheme in which a threshold number of the set of designated verifiers can check the validity of the signature. They also present a concrete MDVS scheme with threshold verifiability in the standard model. Moreover, they compare their scheme with other existing MDVS schemes. Finally, they briefly explain scenarios in which the proposed pattern can be applicable. 1 Introduction Digital signature is an important primitive to provide integrity and authenticity of messages in security protocols [1]. A traditional digital signature scheme is publicly verifiable, that is every entity can check the validity of the signature by the signer's public key. The privacy of the signer is not preserved in a traditional digital signature, since a verifier can convince any third party that the signer has really signed a message by presenting the signer's signature on the message to the third party. As a result, although the public verifiability of digital signatures is a useful and necessary property in many applications, it is not a desirable property in applications such as e-votings, e-auctions and fair exchanges in which integrity and authenticity are required without disturbing the privacy of the signer. Many researchers have proposed different solutions to overcome the conflicts between the authenticity and the privacy of the signer in digital signatures. In 1989, Chaum and Van Antwerpen [2] introduced the concept of undeniable signature in which some help of the signer is required in the verification phase. To avoid the interaction between the signer and the verifier, the concept of designated verifier signature (DVS)/proof was presented by Jakobsson et al. [3] and independently by Chaum [4] in 1996. In a DVS scheme, a signer (Alice) can convince a designated verifier (Bob) that she has really signed a message, while Bob cannot transfer this conviction to any third party since he can produce a signature indistinguishable from that generated by Alice. As a result, the authenticity of Alice is proved to Bob and also her privacy is preserved at the same time, without any interaction between Alice and Bob. In [3], Jakobsson et al. also introduced the concept of strong DVS, in which the private key of the designated verifier is required to verify the signature. In [5], Steinfeld et al. introduced the concept of universal DVS in which every party who holds the signer's traditional signature on a message is able to transform it to a designated signature for a specific verifier. In [3], the idea of multiple designated verifiers was discussed. Later in 2003, Desmedt proposed the concept of multi-designated verifiers signature (MDVS) scheme as a generalisation of a DVS [6]. This notion was first formalised in 2004 by Laguillaumie and Vergnaud [7]. Since then, a number of MDVS schemes with various properties in different setting models have been proposed [8-23]. These MDVS schemes are categorised in the two following patterns: In the first pattern, every verifier of the set of designated verifiers is able to verify the validity of the signature by its own [3, 7, 9-14, 16-18, 21, 23]. This pattern is categorised in two cases: a The verification algorithm does not take any private keys of designated verifiers as input [3, 7, 12-14]. b The verification algorithm takes the private key of a single verifier of the set of all designated verifiers as input [9-11, 14, 16-18, 21, 23]. In case 1, everyone who receives the signature can verify it, because any private keys of designated verifiers are not required in the verification phase. Hence, although the designated verifiers cannot transfer the signer's signature to any third party (since they can produce a signature indistinguishable from that generated by the signer), the privacy of the signer is not preserved, because everyone who receives the signature from the channel between the signer and the designated verifiers can verify it and convince about the signer's signature. This event contradicts the main goal of a DVS namely to preserve the privacy of the signer. As a result, we only consider case 2 as the first pattern in the rest of the paper. In the second pattern, all designated verifiers have to cooperate in order to verify the validity of the signature, since the verification algorithm takes the private keys of all designated verifiers as input [8, 15, 19, 20, 22]. In this paper, we propose a new pattern for an MDVS in which a threshold number of the set of designated verifiers are able to verify the validity of the signature, cooperatively. We also present a concrete MDVS scheme with threshold verifiability in the standard model, based on the proposed generic pattern. Moreover, after a comparison between the existing schemes with our proposed scheme, we explain scenarios in which our proposal can be applicable. Note that (M)DVS schemes are applicable in various applications such as e-votings [24], fair exchanges [25] and cloud computing [26, 27]. One can use each of the above patterns (first, second or our pattern) of an MDVS which is appropriate for the corresponding application, i.e. for each application the proper pattern must be selected. The rest of this paper is organised as follows. In Section 2, some preliminaries are provided which will be used throughout this work. Section 3 covers the formal models and the basic security requirements of two existing patterns for an MDVS scheme as well as our proposed generic pattern for an MDVS with threshold verifiability. In Section 4, we present a concrete MDVS scheme with threshold verifiability in the standard model, based on our proposed generic pattern. In Section 5, a comparison between MDVS schemes is provided. We explain about the applications of our proposal in Section 6. Finally, Section 7 contains the concluding remarks. 2 Preliminaries In this section, some required preliminaries are described which will be used throughout the paper. 2.1 Bilinear pairings Let and be two multiplicative cyclic groups of prime order q and let g be a generator of . There exists an admissible bilinear pairing if and only if the following properties are satisfied: Bilinearity: , for all . Non-degeneracy: i.e. . Computability: There exists an efficient algorithm for computing . It can be referred to [28] for more details about bilinear pairings. 2.2 Complexity assumptions Some problems in bilinear pairings are considered as hard problems in complexity theory. Some of these hard problems are as follows: Computational bilinear Diffie-Hellman problem: On inputs , for unknown , calculate . Decisional bilinear Diffie-Hellman (DBDH) problem: On inputs , for unknown , and , decide whether . Gap bilinear Diffie-Hellman (GBDH) problem: On inputs , for unknown , calculate with the help of the DBDH oracle . The DBDH oracle is that given and , outputs if and otherwise. Definition 1.It is said that the GBDH assumption holds in , if no -time algorithm has advantage at least in solving the GBDH problem in . 3 MDVS schemes In this section, the formal models and the basic security requirements of two existing patterns and our proposed pattern for MDVS schemes are introduced. 3.1 Formal models of existing patterns An MDVS scheme includes of a signer s and a set of n designated verifiers , and is defined by five main algorithms: Setup, signer key generation (SKG), verifiers key generation (VKG), designated signature generation (DSign) and designated signature verification (DVer). Two existing patterns are similar in all algorithms except in the DVer algorithm. These algorithms are defined as follows [7-23]. Setup: It is a probabilistic polynomial time (PPT) algorithm which takes as input a security parameter k and outputs system parameters params, i.e. SKG: It is a PPT algorithm which takes as input params and outputs a private/public key pair for the signer, i.e. VKG: It is a PPT algorithm which takes as inputs params and the number of verifies n, and outputs private/public key pairs for , i.e. DSign: It is a PPT algorithm which takes as inputs a message m, the system parameters params, the signer's private key and n designated verifiers’ public keys , and outputs a designated signature on message m, i.e. DVer: This algorithm is defined differently in two existing patterns. DVer in the first pattern [18]: It is a deterministic polynomial time algorithm which takes as input params, the message/designated signature pair , the signer's public key , the verifiers’ public keys and one verifier's private key and outputs if the designated signature is valid and otherwise, i.e. DVer in the second pattern [19]: It is a deterministic polynomial time algorithm which takes as input params, the message/designated signature pair , the signer's public key , the verifiers’ public keys and all verifiers’ private keys , and outputs if the designated signature is valid and 0 otherwise, i.e. 3.2 Formal model of our proposed pattern Here, we propose a pattern for an MDVS in which the signature can be verified by the cooperation of a threshold number of designated verifiers. In the rest of the paper, we use the notation MDVS for an MDVS which is verifiable by the cooperation of a threshold number t of n designated verifiers. Our pattern is also defined by five main algorithms: Setup, SKG, VKG, DSign and DVer. The Setup, SKG, VKG and DSign algorithms are defined similar to the existing patterns with an extra assumption that in the VKG phase, n designated verifiers may run a secret sharing [29] between themselves in order to obtain their shares of other verifiers’ secret keys. Moreover, the DVer algorithm is defined as follows. DVer: It is a deterministic polynomial time algorithm which takes as inputs params, the message/designated signature pair , the signer's public key , the verifiers’ public keys and t verifiers’ shares of all verifiers’ secret keys , and outputs if the designated signature is valid and otherwise, i.e. 3.3 Security requirements Correctness, unforgeability and non-transferability (source hiding) are three basic requirements of an MDVS scheme [7]. Correctness: Correctness must be satisfied in an MDVS scheme. This property is considered as follows: In the first pattern [18], if then the output of (for all ) must be . Furthermore, for any values , and , if there exists an such that then for any , it must hold that In the second pattern [19], if then the output of must be . In our pattern (i.e. MDVS), if then the output of must be 1 for all s. In other words, if is a valid designated signature on message m, it must pass the DVer phase which is performed by the cooperation of every t verifiers of the set of all verifiers. Unforgeability: Unforgeability is considered as existential unforgeability against chosen message attack and is defined by the following game between an adversary and a challenger [7]. Setup: runs Setup, SKG and VKG algorithms to obtain and gives to . Oracle accesses: has access to the following oracles: : Refers to the designated signature oracle which takes as input a message m and outputs . : Refers to the verification oracle which takes as input a pair and outputs if is a valid MDVS on m, and otherwise. Forgery: outputs . ( is not allowed to submit a query from with input .) It is said that wins the unforgeability game if is a valid designated signature on , i.e. In the first pattern, there exists a public key such that In the second pattern In our proposed pattern, for all s, it holds that Definition 2.It is said that an MDVS scheme is unforgeable, if no PPT adversary with at most queries from and queries from can win the unforgeability game in time at most with probability at least . Non-transferability (source hiding): Non-transferability is considered to guarantee the privacy of the signer. Non-transferability is ensured by a transcript simulation algorithm that can be performed by the cooperation of all designated verifiers to generate a signature which is indistinguishable from the one that should be generated by the signer. This property is defined the same in two existing patterns [7-15, 17-23], as well as our proposed pattern (this property is defined a little different in [16]). Definition 3.It is said that an MDVS scheme is non-transferable if there exists a PPT transcript simulation algorithm (TS) that on inputs public parameters params, the signer's public key , the set of all verifiers’ public/private keys and a message m, outputs a designated signature , which is indistinguishable from which is produced by the signer. In other words, for all PPT algorithms , for any security parameter k, , , and any message m, the value of (1)must be negligible. Remark 1.We must emphasise that unforgeability and non-transferability are considered as two basic security requirements for an MDVS scheme. However, there are some enhanced security requirements such as strong unforgeability, resistance against rogue-key attack, resistance against consistency attack and resistance against key exposure attack [17]. Unfortunately, there is not any security model for an MDVS which guarantees all these security requirements in the literature. In other words, in almost all schemes only unforgeability and non-transferability are modelled and proved. The scheme in [19] (which we will use it as the base of our concrete scheme) not only satisfies unforgeability and non-transferability in the standard model, but also it seems to be resistant against all other mentioned attacks, except the rogue key attack which can easily be solved by a proof of knowledge of a party's private key [17]. Note that this proof of knowledge is commonly applied in the traditional public key infrastructure by a certificate authority. Remark 2.In 2005, a new security notion called as non-delegatability was proposed for DVS schemes [30]. According to this property, neither the signer nor the designated verifier is able to delegate the signing rights to a third party without revealing his/her private key. To the best of our knowledge, no non-delegatable MDVS scheme has been proposed in the literature till now (see [31]). Moreover, Tian et al. [32] pointed out that although the non-delegatability has been a focus of many recent researches, it may be undesirable in some applications. Therefore, the non-delegatable DVS schemes should be considered as a special category which are useful in specific applications where the responsibility of the signer is important and cannot be delegated to another entity. Hence, we do not consider this property in our proposal. According to Remarks 1 and 2, we just consider the basic requirements of an MDVS namely correctness, unforgeability and non-transferability in our proposed new pattern. Moreover, the threshold verifiability is another security requirement of our proposal. Threshold verifiability: This property is only considered in our proposed pattern for a MDVS scheme and guarantees that at least the cooperation of a threshold number of designated verifiers is necessary in order to verify the validity of the signature. In other words, every subset of the set of n designated verifiers with t or more members should be able to check the validity of the signature, cooperatively and no subset of the set of n designated verifiers with less than t members can cooperate to check the validity of the signature. Definition 4.A MDVS scheme is threshold verifiable if the signature can only be verified by the cooperation of at least t designated verifiers. In the next section, we propose a concrete MDVS scheme and prove its security requirements in the standard model (without random oracles). 4 Proposed concrete MDVS scheme In this section, we present a concrete MDVS scheme and prove its security requirements in the standard model (without random oracles). In [19], a universal designated multi-verifier signature scheme is presented in the standard model in which the cooperation of all designated verifiers is necessary to check the validity of the signature as the mentioned second pattern in Section 3. Ming and Wang [19] use the waters’ signature [33] as the base of their scheme. We use the scheme in [19] as the base of our proposed concrete MDVS scheme in this section. Furthermore, we use Shamir secret sharing [29] to provide threshold verifiability. 4.1 Our concrete scheme In this section, we use Waters’ signature [33] and Shamir secret sharing [29] to propose our concrete MDVS scheme. For generality, messages can be considered of arbitrary lengths and a hash function can be used to convert messages to the specific length . The algorithms of our concrete scheme are as follows. Setup: This PPT algorithm takes a security parameter k as input and outputs system parameters in which and are two cyclic groups with prime order q of size k, g is a generator of and is an admissible bilinear pairing. Other parameters are random elements of , i.e. . SKG: This PPT algorithm on input params picks a random as the private key of the signer and computes the corresponding public key as , then outputs . VKG: This PPT algorithm on inputs params and the number of designated verifiers n picks a random element as the private key of the i th verifier, , and computes the corresponding public key as , then outputs for . Furthermore, in this phase, n designated verifiers run a Shamir secret sharing [29] between themselves in order to obtain their shares of other verifiers’ secret keys. This secret sharing is performed as follows: generates a polynomial of degree as follows: where , and for . broadcasts for . computes the ’s share of his secret key as and sends it to . Upon receiving from , verifies the correctness of his share by checking whether the equality holds or not. If the equality does not hold, requests from to send him his share again. computes his total share as . (Note that by these assignments we have , where s are Lagrange coefficients, i.e. , where ). DSign: Let denotes the th bit of the message m of length . Define to be the set of indices such that . The signer, with the private key , selects a random and computes Waters’ signature as follows [33]: Then, the signer sets and computes , where , , is the public key of the i th designated verifier. The signer outputs as her designated signature for n designated verifiers. DVer: In this phase, on inputs a message/designated signature pair , every t members of the set of n designated verifiers are able to verify the validity of the signature, cooperatively. Without the loss of generality, let , , be the t verifiers who cooperate to check the signature. These t verifiers run the following stages in order to verify the validity of : Initially, each computes where is the public key of the signer. Every , , computes , where as described in the VKG phase. Then broadcasts to other verifiers who are cooperating to verify the signature, i.e. , . can verify the correctness of the received share of , i.e. , by checking the following equality: (2) If (3) does not hold, requests from to send him his share again. Note that , g and are known to and can also compute as follows: where s (for and ) were broadcasted in the second stage of the VKG phase. The signature is accepted if and only if the equation (3)holds, where s are Lagrange coefficients. 4.2 Security analysis As mentioned in Section 3, correctness, unforgeability, non-transferability (source hiding) and threshold verifiability are four basic requirements for a MDVS scheme. In this subsection, we analyse these properties of our proposed scheme. 4.2.1 Correctness Lemma 1.Correctness is satisfied in our MDVS scheme. Proof.In the DVer phase, t verifiers check whether the equality (3) (i.e. ) holds or not to verify the signature. We have Hence, if is a valid designated signature on m, then the output of is for all s. In other words, passes the DVer phase which is performed by the cooperation of every t verifiers of the set of all verifiers. □ 4.2.2 Unforgeability Theorem 1.The proposed MDVS scheme is unforgeable, assuming that GBDH assumption holds in , where where is the required time for to forge a signature, and denote the time for computing an exponentiation in and , respectively, and is the time for a pairing computation in . Proof.Since Waters presented his ID-based encryption and signature scheme in the standard model in 2001 [33], many researchers have used his ideas to present and prove different encryption and signature schemes in the standard model [19]. We also use the Waters’ techniques to prove the unforgeability of our scheme. Our method of proof is similar to the method presented in [19] with some differences in details.Suppose that there exists an adversary who can break the scheme by running the unforgeability game according to Definition 2. By this assumption, we can construct an algorithm which can solve a GBDH problem in time at most with probability at least by using as a sub-routine.A random GBDH challenge is given to and tries to calculate with the help of the DBDH oracle . In order to solve this problem, runs as a sub-routine. plays the unforgeability with and simulates and all oracle accesses for in this game, as follows: Setup: sets an integer and chooses an integer ( is the length of the message). Assume that and as a result . also randomly selects and . These values are kept internal to . In order to follow the proof more easily, define two following functions: where for a message m, is the set of indices such that . Then assigns the public key of the signer, the public keys of designated verifiers and other unknown system parameters as follows (Note that are the inputs of the GBDH problem which is trying to solve it.): assigns the public key of the signer as . selects random numbers for and sets as n designated verifiers’ public keys. sets . assigns and for . By this assignment, for any message m we have Afterwards, returns (for ) and to . From the perspective of , all distributions are identical to those in the real world. Oracle accesses: has access to the and oracles as mentioned in Section 3.3. plays the role of theses oracles, i.e. when inputs its queries to these oracles, will generate the corresponding outputs for as follows: o : On input a message m, this oracle must output a valid designated signature on m. When gives the message m as input, must generate a valid without the knowledge of the private key of the signer and designated verifiers (Note that does not know ). To produce , acts as follows: If mod q, aborts and reports a failure. If mod q, randomly selects . Then computes (4) Noting (4) and defining , we have and also Hence, the construction computed by (4) is a valid designated signature on m. o : On input a message/designated signature pair this oracle must output 1 if is a valid designated signature on m and 0 otherwise. When gives the message/designated signature pair as input, must verify the validity of without the knowledge of the private key of the signer and the designated verifiers (Note that does not know .). To verify , acts as follows: If mod q, submits (5)to the DBDH oracle (Note that is trying to solve a GBDH problem and has access to the .). Then outputs 1 to if the output of is 1 and 0 otherwise. It can be easily shown that if is a valid designated signature on m, then the tuple in (5) is a valid BDH tuple, as we have If mod q, can generate a valid designated signature on m as he generates the output of . Afterwards, submits (6)to the DBDH oracle . Then outputs to if the output of is and otherwise. It can be easily shown that if is a valid designated signature on m, then the tuple in (6) is a valid BDH tuple. Note that if is a valid designated signature, we have and also according to (3) (7) Similarly, since is a valid designated signature, we have and (8) According to (7) and (8), we have (9) According to (9) and noting that , and , the tuple in (6) is a valid BDH tuple. Forgery: Suppose that forges a signature on message (Remember that is trying to solve a GBDH problem.). Since creates , acts as follows: If mod q, aborts and reports a failure. If mod q, can solve the GBDH problem by obtaining as follows: (10) It is easy to check that (10) holds, if is a valid signature.Time analysis: Noting the above descriptions we can see that needs a time , for running the game, where is the required time for to forge a signature, and denote the time for an exponentiation in and , respectively, and is the time for a pairing in .Probability analysis: In order to analyse the success probability of , we consider events in which will not abort. will not abort if both the two following events happen [19]: : mod q for all queries from . Let denotes the event that mod q in the i th query from , hence . : mod q. It is easy to see that [19] (11)By defining two events and as mentioned, we have (12)in which is the least success probability of to forge a signature. Noting (11) and that and are independent events, we have (13)where the rightmost equality is implied from .Noting (12) and (13), we have