Abstract
Recently, optimistic fair exchange in electronic commerce (e-commerce) or mobile commerce (m-commerce) has made great progress. However, new technologies create large amounts of data and it is difficult to handle them. Fortunately, with the assistance of cloud computing and big data, optimistic fair exchange of digital items in cyber-physical systems (CPSes) can be efficiently managed. Optimistic fair exchange in cloud-assisted CPSes mainly focuses on online data exchange in e-commerce or online contracts signing. However, there exist new forms of risks in the uncertain network environment. To solve the above problems, we use a new technique called verifiably encrypted identity-based signature (VEIS) to construct optimistic fair exchange in cloud-assisted CPSes. VEIS is an encrypted signature, and we can check the validity of the underlying signature without decrypting it. We introduce a robust arbitration mechanism to guarantee fairness of the exchange, and even the trusted third party (TTP) cannot get the original signatures of the exchange parties. And the TTP in our protocol is offline, which greatly improves the efficiency. Besides, we show that our protocol is secure, fair, and practical.
1. Introduction
1.1. Background
In recent years, optimistic fair exchange in e-commerce and m-commerce has grown fast and information technology has been widely utilized. However, with the development of the information systems, the data are rapidly and continuously created from varieties of devices in the transaction, leaving big challenges for data storage and management. The new cloud-assisted cyber-physical systems (CPSes), which combine the big data, cloud computing, internet of things, and even artificial intelligence with industrial automation, can be used to deal with huge files and complex structures in the fair exchange.
The model of optimistic fair exchange in cloud-assisted CPSes is shown in Figure 1. In such systems, users can purchase the service or store their data in the cloud data service. Besides, they can also use their data to trade with others or sign contracts on digital files. For example, if Alice attempts to exchange her digital content with Bob in another cloud, she needs to perform optimistic fair exchange of signatures in her physical devices (e.g., desktop, laptop, or smartphone).
Although optimistic fair exchange in cloud-assisted CPSes plays a significant role in e-commerce or m-commerce with new capabilities, there still exist risks. Security and privacy issues continue to be a barrier for optimistic fair exchange due to the uncertain network environment. For uncertain environment of fair exchange, we consider two aspects: uncertain contents of the exchange and uncertain activities of the exchange [1, 2]. On the one hand, the exchange parties may not know what will be received before the exchange. On the other hand, no one can make sure the other party does honestly in the transaction. To solve the above problems, we proposed optimistic fair exchange, which is secure and practical in cloud-assisted CPSes.
1.2. Rated Works
Optimistic fair exchange is a common method in e-commerce or m-commerce, in which two parties (e.g., individuals, companies, or systems) exchange their signatures of digital goods fairly. In optimistic fair exchange protocols [3, 4], we usually consider three parties, two exchange parties and a trusted third party (TTP, also called arbiter). Suppose Alice and Bob are parties involved in the protocol, and they need to exchange their signatures of contracts. In the protocol, Alice first sends a partial signature to Bob, and Bob then checks the validity of the partial signature. If it is invalid, Bob stops the protocol. Otherwise, Bob sends his full signature to Alice. Alice then checks whether Bob’s full signature is valid. If it is valid, then Alice sends her full signature to Bob. If Bob does not receive Alice’s full signature or receives an invalid signature, then Bob submits his full signature and Alice’s partial signature to the TTP, the TTP first checks whether Bob’s signature is valid. If it is valid, then the TTP converts the partial signature to the full signature and returns it to Bob. At the same time, the TTP returns Bob’s full signature to Alice as well. Otherwise, the TTP does nothing.
There are other fair exchange protocols which use different technologies. In [5], the authors proposed a fair document exchange, which protected the anonymity of signers. Their another work [6] offered the protection of the private information and provided offline signature recovery. Fan et al. [7] used watermarking technology to construct fair content exchange in cloud computing; however, they did not give the full security proof. In [8], they showed optimistic fair exchange protocols which can be used in file sharing system with a high volume of data exchanged. However, all the above schemes have weaknesses. We compare these schemes with ours in the following aspects. The results are shown in Table 1.(i)Identity-based cryptosystem: it does not need to exchange public and private keys and does not need key directories; thus, it has better efficiency than PKI-based cryptosystem.(ii)Semitrusted third party (TTP): since malicious TTP may leak the information of the users, we need to use semi-TTP to replace fully trusted arbiter.(iii)Strong security: security is important for optimistic fair exchange; however, we find some schemes do not satisfy strong security since they do not give the attack model and security proof.
A kind of technique called verifiably encrypted signature (VES) can be used to construct optimistic fair exchange in cloud-assisted CPSes. VES is an encrypted signature, and we can check the validity without extracting the original signature. Some optimistic fair exchange protocols based on VES [9–13] have been proposed. However, most of them are based on Public Key Infrastructure (PKI), thus leading to the high cost in authenticating and managing the public keys. Fortunately, several identity-based VES schemes [9, 10, 12] have been proposed since identity-based cryptosystems can be used to reduce the cost in public key distribution and management. Most identity-based schemes are more efficient. With regard to security, most schemes consider only if an adversary cannot forge a valid original signature and a valid VES. However, they do not consider stronger security attributes: Can anyone forge a valid VES while the underlying signature is invalid? Meanwhile, many schemes do not give the attack model and security proof. Therefore, even though the schemes [9, 10, 12] are highly efficient, they are not very secure. We compare our scheme with the above schemes in four aspects in Table 2:(i)Identity-based cryptosystem: it greatly reduces the cost in management of the public keys because it does not need to exchange public and private keys and does not need key directories.(ii)Standard model: the security proof of a scheme does not use random oracle model.(iii)Strong security: it means that the scheme satisfies three different security properties at the same time. The properties include opacity, unforgeability, and extractability. Meanwhile, there should be the attack model and security proof.(iv)High efficiency: the lower the computational overhead involved in a scheme, the higher the efficiency. Therefore, high efficiency means less use of complex mathematical operations, including exponential, hash, and bilinear operations, while maintaining strong security properties. For a detailed computational overhead, refer to Table 3.
Motivated by the above works, we construct an optimistic fair exchange protocol with a new kind of VES scheme which combines an identity-based signature scheme and a PKI-based encryption scheme. In this way, we can achieve secure and efficient fair exchange in cloud-assisted CPSes.
1.3. Our Contributions
Technically, we use a new cryptographic technique called verifiably identity-based signature (VEIS) to construct the optimistic fair exchange protocol. The VEIS scheme which combines an identity-based signature scheme [16] and the ElGamal encryption scheme [17] allows us to exchange signatures in the cloud-assisted CPSes easily. Besides, we define the security properties according to the major requirements of optimistic fair exchange in cloud-assisted CPSes. The properties include opacity, unforgeability, and extractability. Opacity guarantees that no one can extract a valid signature from a VEIS without the private key. Unforgeability means that no one can forge a VEIS without the signing key of his identity. And extractability means that if a VEIS is valid, then a valid signature can be pulled out from it.
Then, we construct optimistic fair exchange in cloud-assisted CPSes with our VEIS scheme. In our protocol, two parties (Alice and Bob) may exchange their digital signatures in cloud with their physical devices. Then, Alice first generates her VEIS and sends it to Bob. Next, Bob sends his identity-based signature to Alice if Alice’s VEIS is valid. Finally, Alice sends her identity-based signature to Bob. If cheating occurs during the exchange, the trusted third party (TTP) will get involved and ensure the fairness. Our protocol protects the privacy of the exchange parties since TTP will not get the original signatures of them. Besides, TTP only involves in the exchange when cheating occurs and it reduces the communication cost. The arbitration mechanism guarantees the fairness of the exchange, which means both parties obtain the other’s signature or neither does when the protocol ends. Finally, we report the results of the simulation, which show that our protocol is efficient.
1.4. Outline
We organize the rest of this paper as follows. In Section 2, we give some relevant notions and show the building blocks of our scheme. In Section 3, we present the verifiably encrypted identity-based signature (VEIS) scheme which is used to construct our optimistic fair exchange in cloud-assisted CPSes. In Section 4, we construct the optimistic fair exchange protocol with offline TTP. Then, we discuss the security and fairness of our protocol. In Section 5, we show the results of the simulation. Finally, we conclude in Section 6.
2. The Main Text
2.1. Bilinear Maps and Complexity Assumption
We first briefly review the bilinear maps and complexity assumptions below.
2.1.1. Bilinear Maps
Let and be groups of prime order p and be a generator of , then we say that is an efficient and computable bilinear map if it satisfies the following properties, i.e., (1) Bilinear: , we have . (2) Nondegenerate: : clearly, the bilinearity implies that , we have .
2.1.2. Complexity Assumptions
CDH problem: given , , and , compute .
If the probability that adversary solves the CDH problem is at least ϵ, we have
Then, CDH assumption is as follows.
Definition 1. The -CDH assumption holds if no adversary runs at most t times and has at least ϵ advantage in solving the CDH problem on .
The aggregate extraction problem: given , , , , , and , compute .
If the probability that adversary solves the aggregate extraction problem is at least ϵ, we haveThen, aggregate extraction assumption is as follows.
Definition 2. The -aggregate extraction assumption holds if no adversary runs at most t times and has at least ϵ advantage in solving the aggregate extraction problem on .
2.2. Building Blocks
Our optimistic fair exchange protocol is mainly based on Paterson’s identity-based signature (IBS) scheme [16] and ElGamal encryption scheme [17], which are described as follows.
2.2.1. Paterson’s IBS Scheme
Let and be groups of prime order p and be a generator of . There exists an efficient and computable bilinear map . All identities and messages will be assumed to be bit strings of length and , respectively. We can also let identities be bit strings of arbitrary length and and be the output length of collision-resistant hash functions, and . The signature scheme is defined by the following algorithms. Setup: a secret and generator of are chosen at random. Then, set the value and choose randomly in . Additionally, pick elements , randomly and vectors , of length and , where and are randomly chosen from . The public parameters are and the master secret key is . Extract: let be a bit string of length representing an identity and let be the ith bit of . Define to be the set of indices i such that . A private key for identity is generated as follows. First, choose a random . Then, compute Sign: let be a bit string of length representing a message. Furthermore, let be a set of indices j such that . A signature of on is constructed as follows: First, pick a random . Then, compute Verify: suppose we wish to check if is a valid signature of an identity on . The signature is accepted if it holds that
2.2.2. The Modified Signature Scheme
In Paterson’s IBS scheme, we find one element of the signature () is a part of the private key () and it is not allowed in the strictest sense. Thus, we randomize the first two elements, including the secret key part of the original signature. Let be Paterson’s IBS scheme, and the new IBS scheme is as follows: and are the same as Setup and Extract, respectively. : choose random and compute : we can check the validity of the signature by the following equation:
If the equation holds, then the signature is valid. Otherwise, it is invalid.
The modified signature scheme is existentially unforgeable and the security proof is almost the same as stated in [16], we will not prove it again. We use the following theorem to show that.
Theorem 1. The modified identity-based signature scheme is existentially unforgeable if the CDH assumption holds.
2.2.3. The Encryption Scheme
In the ElGamal encryption scheme, KeyGen generates a pair of keys , where is a generator of . Enc takes as input , a message , and outputs ciphertext , where t is randomly chosen from . Dec takes as input C, the secret key , and outputs the message .
3. Verifiably Encrypted Identity-Based Signature
Verifiable encrypted identity-based signature (VEIS) is an encrypted identity-based signature, allowing its validity to be checked without decryption. We encrypt the identity-based signature with the public key encryption scheme. In fact, our scheme is a weak version of the identity-based verifiably encrypted signature scheme as stated in [18]; thus, we call it verifiably encrypted identity-based signature (VEIS). Informally, the VEIS system works as follows. A private key generator (PKG) generates private keys for the signers, and a key generator (KG) generates keys pairs for the adjudicator. A signer generates a signature on a message with a signing key associated with his identity, then encrypts it with the adjudicator’s public key, and obtains a VEIS. A verifier can publicly check whether the VEIS is valid. The adjudicator can decrypt VEIS with his private key and get the original signature. We now present our definition of VEIS, as well as several properties.
3.1. Modelling VEIS
Formally, a VEIS scheme is defined as follows. Setup: it takes as input a security parameter and then outputs two pairs of keys, for PKG and for the adjudicator. SKG: PKG inputs , a master secret key , and a signer’s identity and outputs a private key for the signer. VESign: it takes as input a signing key of identity and a message ; a signer first generates a signature σ and then he encrypts it with the public key and outputs a VEIS . VEVer: deterministic algorithm VEVer takes as input a message , a VEIS ω, and verification keys , , and and then outputs a bit , where . If , then VEIS is valid. Otherwise, it is invalid. Adj: the adjudicator takes as input ω and , decrypts VEIS, and then obtains a signature . Ver: a verifier can check whether the signature is valid. That is, , where . If , the signature is valid. Otherwise, the signature is invalid.
3.2. Security Definitions
In [11], Boneh et al. proposed two security definitions of verifiably encrypted signature (VES), i.e., unforgeability and opacity. Unforgeability means that no one can forge a VES without the signing key. Opacity guarantees that no one can extract a valid signature from a VES without the adjudicator’s private key. In fact, we find that the VES scheme in [11] missed an important property, i.e., extractability. Extractability means that a valid signature can be extracted from a VES if it passes the check. And we require that extractability must hold even when the master public key and encrypted signatures are maliciously generated.
We now formalize three security definitions of VEIS, i.e., unforgeability, opacity, and extractability. They are all defined in games which are played by a challenger and an adversary. Besides, we define the following oracles:(i)Signing key oracle: the adversary can make a query for a private key associated with an identity of a signer, the challenger first gets the master key, runs SKG, and then responds with the private key .(ii)VEIS oracle: the adversary can make a query for a VEIS on message of an identity ; the challenger first gets a private key of , runs VESign, and responds with a VEIS ω.(iii)Adjudication oracle: the adversary can make a query for a signature by providing a message , a VEIS ω, and an identity . The challenger first gets the decryption key, runs Adj, and responds with a signature σ.
Then, the security definitions are as follows.
Definition 3. Unforgeability is defined by the game . The involved parties in the game are a challenger and an adversary .(i)Setup: the challenger sets up the system, generates the public parameters, and sends them to .(ii)Query: submits an identity to Signing Key Oracle and obtains a signing key . can make at most queries for signing keys. submits an identity , a message to VEIS Oracle, and obtains a VEIS ω. can make at most queries for VEIS. submits a message , a VEIS ω, and an identity to Adjudication Oracle and obtains a signature σ. can make at most queries for signatures.(iii)Forge: finally, submits a tuple to the challenger, where the adversary never queried Signing Key Oracle at , VEIS Oracle at , or Adjudication Oracle at . If , wins in the above game.A VEIS scheme is unforgeable if for any probabilistic polynomial time (PPT) adversary , the probability that wins in the above game is negligible.
Definition 4. pacity is defined by the game as follows. Similarly, a challenger and an adversary get involved in the game.(i)Setup: the challenger sets up the system, generates the public parameters, and sends them to .(ii)Query: submits an identity to Signing Key Oracle and obtains a signing key . can make at most queries for signing keys. submits an identity , a message to VEIS Oracle, and obtains a VEIS ω. can make at most queries for VEIS. submits a message , a VEIS ω, and an identity to Adjudication Oracle and obtains a signature σ. can make at most queries for signatures.(iii)Forge: finally, submits a tuple to the challenger, where the adversary never queried Signing Key Oracle at , or Adjudication Oracle at , and can get from VEIS Oracle. If is a valid signature on of identity , wins in the above game.A VEIS scheme is opaque if for any PPT adversary , the probability that wins in the above game is negligible.
Definition 5. Extractability is defined by the game , which involves a challenger and an adversary .(i)Setup: the challenger sets up the system, generates the public parameters, and sends them to .(ii)Query: submits an identity to Signing Key Oracle and obtains a signing key . submits a message , a VEIS ω, and an identity to Adjudication Oracle and obtains a signature σ.(iii)Forge: submits a tuple to the challenger.(iv)Extract: the challenger runs Adj and gets . If we have and , which means that the signature is invalid, then wins in the above game.A VEIS scheme is extractable if for all PPT adversaries , the probability that adversaries wins in the above game is negligible.
We require that if a VEIS scheme satisfies the unforgeability, opacity, and extractability, then it is secure.
3.3. The Proposed VEIS Scheme
We now present the concrete VEIS scheme. A VEIS scheme consists of following algorithms. Setup: it takes as input a security parameter and generates the system parameters. Let and be groups of prime order p, be a generator of , and e be a bilinear map; that is, . An identity for a signer is denoted by . We assume that the length of the identity is . If it is not, then we use a hash function to obtain -length identity. Then, choose -length vectors and -length vector at random, where , . Besides, pick random , . Choose random as the secret value. Compute . Choose randomly. Then, set the master secret key and the master public key . Besides, choose random and then set the private key for adjudication as , and the public key is . SKG: it takes as input an identity of a signer, , and the master secret key and outputs a private key for signing as follows. First, let be the set of indices i such that , where is the ith bit of . Then, choose a random and compute VESign: it takes as input a signing key and a message and generates a signature as follows. Let be the set of indices j such that , where is the jth bit of . Then, choose a random and construct a signature by computing Then, we construct a VEIS as follows. In fact, since and are independent with the message and identity , we only need to encrypt . Choose a random and construct the VEIS by computing VEVer: if the following equation holds: then, the VEIS is valid and the verifier outputs 1. Otherwise, he outputs 0. Adj: it takes as input ω and and outputs a signature by computing Ver: it checks whether is valid. If the equationholds, then the signature is valid and Ver outputs 1. Otherwise, Ver outputs 0 to show σ is invalid.
Our scheme is secure in the standard model, and the security proof will be shown in the next section.
4. Optimistic Fair Exchange in Cloud-Assisted CPSes
In this section, we construct optimistic fair exchange in cloud-assisted CPSes based on the proposed VEIS scheme. The system model is shown in Figure 2. Two parties (known as Alice and Bob) may want to exchange their signatures on digital goods in cloud. They first get their private keys from a private key generator. Then, they perform our optimistic fair exchange protocol and get the signature of each other fairly. If there exist disputes, they can ask the TTP for arbitration.
4.1. Optimistic Fair Exchange Protocol
It is more straightforward to design the fair exchange protocol with online TTP than optimistic fair exchange (fair exchange protocol with offline TTP). However, optimistic fair exchange is more efficient since it greatly reduces the workload on the TTP. In the optimistic fair exchange protocol, the TTP only involves in the exchange when someone attempts to cheat. And TTP in our protocol will not get the original signature of the parties in the exchange. Without loss of generality, we assume Alice and Bob have agreed on two files and , and Alice is the protocol initiator. The concrete protocol is as follows:(i)Initialization: take as input security parameter , run , and output master public key and the master secret key . Besides, the TTP chooses random , and then he sets a key pair for adjudication as . Similarly, A and B choose random , and then set their key pairs as and , respectively.(ii)Registration: a user can register with his identity and obtain a signing key. Let be a bit string of length and let be the ith bit of . Define to be the set of indices i such that . The signing key for identity is computed as follows:(iii)Exchange: let and be identities of A and B, respectively. Then Alice and Bob will obtain their signing keys and , respectively. The time denotes the maximum time Alice can wait, and the time denotes the longest the Bob can wait. Then, the optimistic fair exchange of identity-based signatures is as follows: (1) Alice first generates her identity-based signature (on ) as Then, she encrypts it with the new public key and obtains Then, she sends to Bob. (2) Bob quits if he waited more than . Otherwise, after receiving from Alice, Bob checks whether the following equation holds: If the equation holds, then is valid and it implies that the identity-based signature is valid as well. Bob generates his identity-based signature (on ), encrypts it with the new public key , and obtains Then Bob sends to Alice.(3)Alice invokes Protocol Abort and then quits if she waited more than . Otherwise, within the time , Alice receives from Bob and checks whether it is valid by the following equation: If the equation holds, Bob’s signature is valid and Alice sends her identity-based signature to Bob. Otherwise, Alice invokes Protocol Abort and then quits.(4)Bob invokes Protocol Resolve if he waited more than . Otherwise, within the time , Bob receives from Alice and checks it. If it is valid, Bob sends his identity-based signature to Alice. Otherwise, Bob invokes Protocol Resolve and then quits.(5)Alice invokes Protocol Resolve if she waited more than . Otherwise, within the time , Alice receives from Bob and checks whether it is valid. If Bob’s signature is valid, the protocol ends successfully. Otherwise, Alice invokes Protocol Resolve and then quits.(i)Abort protocol:(a)Alice sends an abort command to TTP.(b)The TTP checks the record if there have a command of resolve from Bob.(c)If not, the TTP sends acceptation message to Alice and stores the abort command into record. Otherwise, the TTP sends Bob’s signature .(ii)Resolve protocol: Alice and Bob can use the same Resolve protocol. For convenience, we use Bob as an example to describe the protocol.(a)Bob encrypts with the public key and obtains Then he submits a resolve command to TTP.(b)The TTP checks the record if there is a command from Alice to ask abort the exchange. If it exists, the TTP sends a rejection message.(c)If not, the TTP first checks whether and are valid by the following equations: If either of the equations does not hold, then the TTP refuses the request from Bob. Otherwise, the TTP decrypts with its private key and obtains a new VEIS by computing Next TTP returns to Bob and sends to Alice. Meanwhile, the TTP stores this command into record.(d)Bob can decrypt with his private key and obtains Alice’s signature by computing
4.2. Security
In fact, the security of our protocol can be reduced to the security of the VEIS scheme as stated in [9]. Therefore, we mainly consider the following questions. Can anyone forge a valid original signature? Can anyone forge a valid VEIS? Given a VEIS, can anyone extract a valid signature from it? And there is an extra question which is missed in [9, 10]: Can anyone forge a valid VEIS while the underlying signature is invalid? The above questions are the basis of the security properties. Therefore, we will show that our scheme satisfies unforgeability, opacity, and extractability by the following theorems.
Theorem 2. Our VEIS scheme is unforgeable.
Proof. In fact, if forges a valid VEIS (on ) of identity , he breaks the unforgeability of our VEIS scheme, and we can construct an adversary that breaks the existential unforgeability of the underlying signature scheme. Therefore, the unforgeability of our VEIS scheme can be reduced to the underlying IBS scheme, which is slightly different from Paterson’s IBS scheme. We now prove Theorem 2 by the following two lemmas.
Lemma 1. Our VEIS scheme is unforgeable if the underlying signature scheme is existentially unforgeable.
Proof. If there exists an adversary that forges a tuple with a nonnegligible probability ϵ and it holds that , then breaks the unforgeability of the VEIS scheme. And we can construct an adversary that breaks the existential unforgeability of the underlying signature scheme.
We assume that and play the game , and simulates the challenger and tries to break the underlying signature scheme. We now show how to construct . Setup: runs algorithm Setup and gets the master secret key , the master public key , the adjudicator’s public key , and adjudicator’s private key . Then he sends and to , which are indistinguishable from the real ones. Query: simulates oracles as follows:(a)Simulation of signing key oracle: when submits an identity of a signer and requests a private key, chooses at random and computes and then he sends it to .(b)Simulation of VEIS oracle: when submits a message and an identity and requests a VEIS, first gets a private key of as he does in Simulation of Signing Key Oracle, and he generates the signature as follows: Then, he encrypts the signature with by Finally, he sends to .(c)Simulation of adjudication oracle: when submits a message , a VEIS , and an identity and requests a signature, decrypts the VEIS as follows: Then, he sends the signature to . The simulation above is perfect since does it honestly. Forge: finally, submits a tuple to , where the adversary has never queried Signing Key Oracle at , VEIS Oracle at , or Adjudication Oracle at . If , then we have (it implies the extractability of VEIS and we will prove this later), and can decrypt the VEIS and obtain a valid signature as follows:Thus, forges a valid signature with a nonnegligible probability ϵ. This completes the proof.
Lemma 2. The modified signature scheme is existentially unforgeable.
The proof is almost the same as stated in [14], and we use Theorem 1 to show that.
Theorem 3. Our VEIS scheme is opaque if the aggregate extraction assumption holds, and the underlying signature scheme is existentially unforgeable.
Proof. Suppose adversary breaks the opacity of the VEIS scheme with nonnegligible probability ϵ, then we can construct an adversary that solves the aggregate extraction problem. and play the game , and simulates the challenger.
The aggregate extraction problem: given , , , , , and , compute .
We now construct as follows: Setup. chooses -length vectors , and -length vector at random, where , . Besides, pick random , . Then he sets , , and the master public key , and public key . Then he sends and to , which are indistinguishable from the real ones. Although does not know and , we can still complete the simulation by playing some tricks. sets and ( can query at most times for private keys and times for VEISs). Then, chooses , , -length vector , and -length vector at random, where and are random values in and and are random values in . Besides, picks , , -length vector , and -length vector , where , , , and are random elements in . Then, sets , , , and , where and . Then, define the following functions for easy analysis: Query. simulates oracles as follows:(a)Simulation of signing key oracle: when submits an identity of a signer and requests a private key, constructs it as follows: Writing , the private key can be simplified as Therefore, the private keys generated by are indistinguishable from the real ones. Then, sends the signing key to .(b)Simulation of VEIS oracle: when submits a message and an identity and requests a VEIS, can use a list to respond. initializes the list and chooses the random index to guess from which VEIS extracts a signature in the list. And has not queried for a signing key at . If , then chooses random , , and in and constructs VEIS as follows. First, computes where . Then, he chooses random t and encrypts the signature with as follows: If , then chooses random , , and sets Finally, he sends the VEIS and to and stores the tuple , in . If one of , , , and holds, stops the game (if one of them holds, cannot solve his problem). We denote this event by . Otherwise, the simulation is perfect.(c)Simulation of adjudication oracle: in this phase, is not allowed to make a query on . When submits a message , a VEIS , and an identity and requests a signature, first checks whether the tuple is in the list ; if it is not in , then the VEIS is invalid and returns (if the VEIS is valid, then forges a valid VEIS, and this contradicts the unforgeability of our VEIS scheme). If the tuple is in the list and , then finds out the tuple and returns to . The simulation above is perfect if has not aborted. Forge: finally, outputs a valid signature extracted from the VEIS; that is, (on message ) of identity with a nonnegligible probability ϵ. That means correctly guesses from which VEIS extracts the identity-based signature, and we denote this event by . Then, solves his problem by computingThen, the probability that has not aborted in the above game is as follows:The probability that correctly guesses the index is , and we deduce since we use proof skills in [16]. Thus, we haveAnd the probability that solves the aggregate extraction problem is at least , which is nonnegligible.
This completes the proof of opacity.
Theorem 4. Our VEIS scheme is extractable.
Proof. The challenger plays the game with an adversary as follows: Setup: the challenger sets up the system, generates key pairs , , and sends the public keys and to . Query: when makes queries, the challenger answers as follows:(a)Signing key oracle: submits an identity , then the challenger chooses random and computes Then, he returns it to .(b)Adjudication oracle: submits a message , a VEIS , and an identity , then the challenger first decrypts the VEIS and obtains Then, he returns to . Forge: finally, outputs a VEIS of the challenge identity and sends to the challenger. Extract: if the given VEIS passes the check, then we haveThen, a signature can be extracted byAnd we haveIt implies that if holds, then always holds as well. Thus, our VEIS scheme is extractable.
4.3. Fairness
To show our protocol satisfies fairness, we consider the cases where Alice or Bob cheats in the protocol.(i)Case 1: Alice has two chances to perform the optimistic fair exchange protocol dishonestly. In step 1, if Alice sends an invalid VEIS to Bob, then Bob will check whether the verification equation holds. Since is invalid, the equation does not hold. Bob detects that is invalid and stops the protocol. In step 3, after receiving Bob’s signature, Alice does not send her signature to Bob or sends an invalid signature to Bob. However, Bob can submit and to the TTP and ask for arbitration. If both and are valid, the TTP decrypts and returns to Bob. Then, Bob decrypts with his private key and obtains Alice’s signature . Therefore, Alice gets no benefits if she cheats in the protocol.(ii)Case 2: Bob also has two chances to perform the optimistic fair exchange protocol dishonestly. In step 1, after receiving the valid signature from Alice, Bob stops the protocol and asks for arbitration without providing his VEIS or providing an invalid VEIS. However, TTP will detect this and return nothing to Bob. In step 2, after receiving the valid signature from Alice, Bob sends an invalid signature to Alice. However, Alice will detect this and refuse to send to Bob. Therefore, Bob also gets no benefits if he cheats in the protocol.
Besides, the TTP will not get useful information of the exchange parties.
5. Simulation
In this section, we report several simulations and the results show that our VEIS scheme and optimistic fair exchange protocol are practical. We conducted experiments with Pairing Based Cryptography (PBC, http://crypto.stanford.edu/pbc/) library. The experiments were compiled in C programming language and carried out on Inter(R) Core(TM) Quad CPU Core i7-6700K @ 4.00 GHz. The security parameter was set to be 160, and the length of an element in group , was 512 bits. The efficiency of our VEIS scheme mainly depends on the length of users’ identities, which was chosen from 32 bits to 240 bits to evaluate the performance of our VEIS scheme and optimistic fair exchange protocol.
Before performing our experiments, we first compare several VES schemes by theoretical analysis. The results are shown in Table 3.
Let E, H, and e denote exponent operation time, operation time of hash function, and pairing operation time, and all the other light-weight operations such as additions and multiplications are omitted. We can find the efficiency of our scheme is comparable with other efficient schemes. The VES schemes in [9, 11] are more efficient; however, Boneh’s scheme is PKI-based and Gu’s scheme is not quite secure. Although VES schemes in [14, 15] are more secure, too many hash operations still reduce the efficiency of the schemes. Our VEIS scheme overcomes their weaknesses and is still efficient. The simulation results are shown in the following papers.
In Figure 3, we show the running time of our VEIS scheme with different length of identities (). We do not consider the length of files () since we have the similar results when only changing . The length of identities is chosen from 32 bits to 240 bits; that is, . And the full time ranges from 120 ms to 688 ms. The algorithm Setup takes roughly the same processing time, which is the biggest part of full operation time. To the contrary, SKG costs about 3 ms, and the rest algorithms costs about 16 ms for different length of identities. Therefore, once the system is set up, it is very efficient for users to generate their VEISs in cloud. Since the private key generator must distribute all users’ keys, we have to evaluate whether it is suitable for a large number of users who take activities in cloud-assisted CPSes. The length of identity is set to be 160 bits, and Figure 4 shows the results. For cloud data services which have 100000 users, our scheme only takes about 350 seconds to generate their signing keys.
In Figure 5, we show the running time of optimistic fair exchange with different length of identities. In the experiments, we do not consider the communication time which is hard to evaluate due to some subjective factors. The full protocol takes less than 1 second when the length of the identity is set to be 240 bits, and it is quite acceptable. Initialization takes a little more time than other phases; however, we only need to perform it once in the system. When two users exchange their signatures of digital files in cloud, they only need to take 50 or 60 ms to finish the transaction. The above results show that our protocol is efficient and practical in cloud-assisted CPSes.
6. Conclusion
Optimistic fair exchange in cloud-assisted CPSes is a kind of protocol in which two parties can exchange their signatures of digital content in cloud. In this paper, we constructed such a protocol with a new cryptographic technique, i.e., verifiably encrypted identity-based signature (VEIS), which is based on Paterson’s IBS scheme and ElGamal encryption scheme. Then, we showed that our protocol is secure with the strictest security proof. Additionally, we discussed fairness of our protocol, and the results showed that both two parties obtain each other’s signature or neither of them get anything useful in the protocol. Finally, the results of the simulation showed that our protocol is practical.
Data Availability
These data relate to the personal privacy of some authors. Therefore, the data used to support the findings of this study are available from the corresponding author upon request via mail ([email protected]).
Conflicts of Interest
The authors declare that they have no conflicts of interest.
Acknowledgments
This work was supported by the National Natural Science Foundation of China (No. U17733115).