Abstract
With the rise of digital images in our daily lives, there is a growing need to provide an image trading market where people can monetize their images and get desired images at prices that fit their budget. Those images are usually uploaded and stored onto centralized image trading service providers’ servers and the transactions for image trading are processed by these providers. Unfortunately, transaction unfairness and users’ privacy breaches have become major concerns since the service providers might be untrusted and able to manipulate image trading prices and infer users’ private information. Recently, several approaches have been proposed to address the unfairness issue by using the decentralized ledger technique and smart contract, but users’ privacy protection is not considered. In this paper, we propose a fair and privacy-preserving protocol that supports image fair exchange and protect user privacy. In particular, we exploit blockchain and Merkle tree to construct a fair image trading protocol with low communication overhead based on smart contract, which serves as an external judge that resolves disputes between buyers and sellers in image transactions. Moreover, we extend a popular short group signature scheme to protect users’ identity privacy, prevent linkability of transactions from being inferred, and ensure traceability of malicious users who may sell fake images and/or refuse to pay. Finally, we design and build a practical and open-source image trading system to evaluate the performance of our proposed protocol. Experimental results demonstrate its effectiveness and efficiency in real-world applications.
1. Introduction
Digital imaging devices such as digital cameras are becoming more integrated in our lives. Before, they were simply used for entertainment purposes. However, people are now starting to use them for a profession, by sharing, selling, and trading pictures and images. As a result, an online market place for image trading is imperative to ensure the success of this profession. To satisfy the needs of image trading, there already exist many image trading service providers (ITSP), such as ShutterStock [1], iStockphoto [2], Fotolia [3], and Dreamstime [4]. They can offer users efficient and convenient image transaction services with a much lower marginal cost than traditional approaches.
The fairness of image transaction in the ITSP, however, is subject to skepticism and scrutiny, as user’s images are stored in the ITSP’s servers and all transactions are completed via the ITSP, who waits to receive money from buyers and images from sellers and only executes the exchange based on the hash computation [5]. Unfortunately, such fully third-party trusted ITSPs are often not available in real world. This is because ITSPs are viewed as a black box to users, thereby being able to manipulate image trading prices and volumes to chase higher profits, resulting in unfairness on users. For example, a seller sells an image for $2, but an ITSP could charge the price for $10 and save $8 for himself, which is obviously unfair to the seller.
In general, in order to complete image transactions more efficiently and conveniently, ITSPs usually requires users to submit their identity information, including phone numbers, e-mail addresses, bank card numbers, and home addresses, for various purposes, such as taxation. However, once these data are sent and stored on the ITSP’s server, users will lose control of their data, leading their private information to be vulnerable to the untrustworthy ITSPs, as well as intruders. Additionally, through analyzing users’ transaction history, malicious ITSPs and intruders are able to infer linkability of transactions which occurred among different users. Even more, a particular user’s transaction habit can be inferred, for example, what type of photos he prefers to buy.
Recent works have been focusing on solving the fairness issue incurring in an image transaction by using the blockchain technique [6–8]. The fairness is guaranteed by relying on a smart contract executed over decentralized cryptocurrencies, where the smart contract takes the role of an external judge that completes the exchange in case of disagreement [6]. In addition to smart contracts, perceptual hashing is leveraged to automatically detect and reject tampered images that are perceptually similar to images that are already present on the marketplace [7]. Besides, Zhao et al. designed an image network copyright transaction protection approach based on blockchain technology [8] so that the entire copyright transaction process is protected and the attribute identification of image content is identified. Unfortunately, these works only consider solving the fairness issue, while addressing the privacy issue at the same time remains to be an open problem.
In this paper, we propose to build a practical image trading system that can provide guarantee on achieving both fairness and privacy protection in an image trading process. The major contributions of this paper are summarized as follows:(i)Fairness in trading is achieved by a fair image trading protocol that is constructed by utilizing blockchain and Merkle tree. Particularly, a smart contract deployed on the blockchain acts as a trusted and automatic judge to complete the image transaction in case of disagreement. Besides, compared to the image trading system that does not support digital goods preview before trading [6], our advantage lies in designing a distributed thumbnail preview mechanism to enhance user-friendliness and further guarantee the authenticity of trading images.(ii)To address user privacy issue, we enhanced a popular short group signature BBS04 [9] to our proposed system so that a verifier is able to verify a signer’s signature on transaction data, while the signer’s identity is kept private from the verifier. In addition, users and intruders cannot infer any private information about a particular user by analyzing his or her image transaction history. Meanwhile, we redefined the role of the group manager [9] and replaced the sole manager with three independent managers to prevent them from maliciously deducing private information of the system. More importantly, we maintain the ability to track malicious users.(iii)We design and build a practical image trading system that is developed from scratch, which can be adopted as a real-world application in the trading market. Moreover, we evaluate the performance of the proposed protocol in terms of the enhanced short group signature module computation cost, fabric network upload and download latency, image block encryption and decryption computation cost on mobile devices, and smart contract judgement cost. Experimental results show that the proposed protocol is efficient and effective in guaranteeing fairness and ensuring privacy protection.
The remainder of this paper is organized as follows. In Section 2, we briefly introduce the building blocks, including Merkle tree, short group signature, IPInter Planetary File System (IPFS), blockchain, and smart contract, which are used in designing our image trading system. In Section 3, we present the system model, problem, and threat model. The detailed design of the proposed protocol is presented in Section 4 and Section 5. Then, the security and privacy of the proposed protocol will be analyzed in Section 6. In Section 7, we introduce the prototyping system that is developed from scratch and evaluate its performance. Finally, we briefly discuss related work in Section 8, and conclude this paper in Section 9.
2. Preliminaries
2.1. Merkle Tree
A Merkle tree is an authenticated data structure where every leaf node of the tree contains the cryptographic hash of a data block, and every nonleaf node contains the concatenated hashes of its child nodes [10].
A contains leaf nodes , where is an integer, is a tagged binary tree = and the th leaf node is labelled by . Furthermore, a label of nonleaf node is the hash value of the labels and , where and are labels for child nodes and , respectively (i.e., , where stands for hash function). We call the of and . We name as the of and vice versa. A of elements , , …, is created by Algorithm 1.
|
The root node of a Merkle tree is labelled as . To prove that an element is one of leaf nodes of the Merkle tree, a is used, which is a vector composed of labels on all the siblings of elements on a path from the th leaf node to the root node. We denote Algorithm 2 for generating a Merkle proof by , which takes a Merkle tree and an index as inputs and outputs a Merkle proof that is the th leaf of .
|
At last, the algorithm (Algorithm 3) takes as input an element , a Merkle proof , and a root of Merkle tree . This algorithm is used to verify whether is a leaf node of the Merkle tree with root using proof . If the verification is successful, the algorithm outputs 1, otherwise, the algorithm outputs 0.
|
2.2. Short Group Signature
The concept of short group signature was first proposed by Boneh et al. [9] in 2004. With short group signature, any member of the group can sign message, but the resulting signature keeps the identity of the signer confidential. More concretely, given a short group signature and a group of users, a verifier cannot distinguish the signer’s identity. This property can be used to preserve the identity of the signer. Compared to the group signatures based on Strong-RSA [11], the length of short group signatures is shorter, about 200 bytes, so it is more suitable for practical applications.
The short group signature scheme is constructed on the Strong Diffie–Hellman (SDH) assumption in groups with a bilinear map. In this paper, we will improve it to construct a privacy-preserving protocol with conditional accountability in our decentralized image trading system.
2.3. IPFS
The InterPlanetary File System (IPFS) [12] is a hypermedia protocol and peer-to-peer network for storing and sharing data in a distributed file system. In a nutshell, IPFS is similar to a network, but it can be viewed as a single BitTorrent swarm that exchanges objects within a single Git repository. Specially, IPFS maintains a high-throughput content-addressable block storage model with content-addressable hyperlinks. This results in a generalized Merkle DAG, a data structure on which people can build blockchains, versioned file systems, and even a persistent network. Importantly, IPFS has no single point of failure and the nodes do not need to trust each other. Distributed content delivery can save bandwidth and prevent DDoS attacks that HTTP schemes may encounter [13]. In this paper, we deployed a four-node IPFS system that stores thumbnail images users plan to trade.
2.4. Blockchain and Smart Contract
Cryptocurrencies are gaining increasing attention from academia and industry in recent years. Cryptocurrencies are based on a public digital ledger that stores all current and historical transactions and is maintained by decentralized miners [14]. The digital ledger is stored in the form of blockchain, and all miners agree on its state through a consensus protocol. Due to its special data structure, the blockchain enables decentralization, transaction immutability, traceability, and transparency. Briefly speaking, the blockchain technique is a decentralized and, oftentimes, public digital ledger, which consists of records called blocks that are used to record transactions across miners, and has drawn much attention from academia recently [15–19].
The smart contract is built on top of cryptocurrencies and allows users to define and execute contracts on the blockchain [20]. In particular, a smart contract is a self-executing computer program and consists of functions (executable units of code within the contract) and data (the state of the smart contract). The program code captures the logical contract terms between multiple parties and predefines trigger conditions and response actions. The execution of functions in a smart contract is triggered by time or events. Ideally, smart contracts can be regarded as executed by a distributed and trusted global machine that will faithfully execute every instruction. With the help of smart contracts, the rules of fair exchange can be enforced without trusted third parties.
The Ethereum is one of the most popular public permissionless blockchain platforms [20]. In short, the Ethereum is a public decentralized network, open to anyone, where participants interact anonymously. There exist two types of accounts in the Ethereum network: externally owned accounts and smart contract accounts. An externally owned account is associated with a unique public-private key pair, owned by someone (e.g., seller, buyer, and committee) who has an Ether balance, and the private key can sign transactions from that account. Contract accounts do not have key pairs. A smart contract account maintains an Ether balance and stores a contract code that determines the flow of Ether in the account. A smart contract account must be activated by an externally owned account. In order to execute a smart contract used to transfer cryptocurrencies, a user-controlled account must pay a certain amount of gas using Ether. The gas fee is actually a transaction fee that encourages miners to incorporate the code execution of the smart contract into the blockchain. Gas can be seen as an indicator of the cost of a regulated smart contract, with each assembly operation having a fixed gas cost based on its expected execution time. However, as more and more Ethereum-enabled applications become available, transaction activities become more frequent and active, leading to ever higher transaction gas fees and lower transaction consensus efficiency.
Hyperledger fabric [21] is another type of blockchain, the permissioned blockhead, and it is designed for use in an enterprise context and offers some key differentiating features compared to the public permissionless blockchain. One of the most important different factors is the support for pluggable consensus protocols, allowing the platform to be more effectively customized to fit specific use cases and trust models. Additionally, fabric can use consensus protocols that do not require native cryptocurrency to incentivize expensive mining or drive smart contract execution. Absence of cryptographic mining operations means that the platform can be deployed at roughly the same operating cost as other distributed systems, meaning that users do not have to afford high gas costs for transactions. Finally, miner nodes are mutually known and not anonymous in fabric network, this means that while miner nodes may not fully trust each other, the network can operate under a governance model that builds on the trust that does exist between miner nodes, such as a legal agreement or a framework for handling disputes. The combination of these differentiated design features makes fabric one of the better performing platforms today in terms of transaction processing and transaction confirmation latency.
3. Problem Statement
3.1. System Model
As illustrated in Figure 1, the system model in this paper involves six parties: a seller, a buyer, a committee, an IPFS system, the Ethereum platform, and a consortium blockchain with smart contract. The seller and buyer upload and download thumbnails from the IPFS via their smart devices. In addition, they exchange data (e.g., Merkle root hash of a traded image) through the smart contract deployed on the consortium blockchain (data flow blockchain). At the same time, the buyer, seller, and committee transfer cryptocurrencies among them on the Ethereum platform. The committee is host-and-curious and made up of three members, which is responsible for generating group public key, issuing group private keys for users and recovering malicious user’s real identity.
When sellers plan to put their images for sale, first of all, they must locally compute and upload thumbnails of images to the IPFS, and then, buyers can view them on their own devices (e.g., smartphones) and decide whether to buy. If yes, the smart contract deployed on the consortium blockchain is used to guarantee the integrity and authenticity of traded images between sellers and buyers. Meanwhile, both sides of the transaction complete a reliable transfer of cryptocurrency corresponding to the value of images based on Ethereum. If disputes arise during the above processes, for instance, the buyer finds that the traded images are fake or the seller does not receive the money, the smart contract will intervene to prevent sellers from selling fake photos and buyers from refusing to pay.
3.2. Research Problem
In this system model, there exist two major issues to be addressed, which are summarized as the following two research problems.
Unfairness: in our system model, unfairness incurs in both buyers and sellers. For an honest buyer, unfairness means not receiving the real photos from sellers after paying for them; for an honest seller, not receiving the money after the real images are delivered to buyers.
Privacy leakage: as mentioned in Section 1, in the traditional image trading system, two types of private information can be compromised. The first one is the user’s identity information, such as name, telephone number, e-mail address, and bank card number, which may be disclosed by ITSPs for profit. The second one is user’s linkability of transactions. Because the fact that the linkability of transactions might reflect the user relationships, user’s consumption habits, and preferences, and once this information is obtained and inferred by a malicious person, it will lead to terrible consequences.
3.3. Threat Model
Fairness threats: based on the system model, fairness threats are likely to derive from all participants in the image trading process, such as sellers, buyers, and committee. Therefore, three types of threats related to the fairness of image trading are possible, which are summarized as follows:(i)Threat1: the seller might use fake images to transact with the buyer and earn illegal profits, which will result in a loss to the buyer(ii)Threat2: the buyer might refuse to pay money to the seller after receiving the traded image, which will cause a loss of seller earnings(iii)Threat3: the committee may embezzle the deposits which are used to complete image transactions between buyers and sellers
Privacy threats: the user’s identity and linkability of image transaction are private and confidential to the committee members, users (buyers and sellers), and intruders. However, a malicious user or an external attacker may want to detect user’s identity information and analyze user’s linkability of image transactions, as, based on these data, they can snoop on the user’s image preference and other more intimate information. In addition, in most cases, the committee members are honest, but some of them still have the incentive to unlawfully reveal the user’s identity. In order to clearly, the privacy threats are classified into the following three items.(i)Threat4: the attacker detects the user’s identity information(ii)Threat5: the attacker infers the user’s linkability of image transactions(iii)Threat6: the attacker analyzes user’s image preference
4. Short Group Signature Scheme with Conditional Accountability
4.1. Overview
As introduced in previous sections, we intent to utilize short group signature to protect user’s identity information, user’s linkability of transactions, and even user’s image preference so that private or sensitive information of users is not disclosed to malicious users and external attackers. However, traditional short group signature (BBS04) [9] cannot be directly used into protecting users’ identity privacy in our protocol. This is because the normal group signature scheme sets up a group manager to simultaneously issue group private key to users and reveal their true identity once they have misbehavior. This is very scary; if the only one manager goes corrupt or is compromised by an attacker, then all the users’ real identity information will be leaked, along with their linkability and image preferences.
Therefore, we design an enhanced short group signature (short for ESGS) scheme with conditional accountability, which is extended from a classic short group signature scheme [9]. This new scheme is not only able to preserve user’s identity privacy but also able to prevent the leakage of user privacy in case of the group manager failure. We will show how to build this enhanced short group signature for protecting user privacy in the Section 4.2.
4.2. Construction of ESGS
ESGS contains four algorithms: , , , and . In , a committee member (named as ) is responsible for generating the group public key , keeping the secret parameter and issuing private key for user . Moreover, each of the other two committee members (named as and ) holds a private key, and , respectively, which are used to jointly recover malicious user’s identity. In , a group member signs the transaction data with his/her private key . A verifier (any group member) is able to check whether the signature of a transaction signed by a group member is correct in . In , if a user is identified by the committee for misbehaviour, such as selling fake photos, then and work together to reveal the true identity of the user using and . Details of this scheme are described in Figure 2.
Consider bilinear groups and with respective generators and . Suppose further that the SDH assumption holds on (, ), and the linear assumption holds on . The enhanced short group signature scheme employs a hash function : , treated as a random oracle in the proof of security. The total number of users in the group is .
KeyGen: selects and and sets . Using generates, for each user , , and SDH tuple selects and sets . At the same time, sends to and via the secure channel. selects and sets such that . Then, sends back to via the secure channel. In a similar way, selects and sets such that . Then, sends back to via the secure channel. Therefore, the group public key of ESGS is . The private key of and is and , respectively. Every user’s private key is his or her tuple . The secret parameter is only known to the private key .
Sign: the user holds his or her private key , invokes the smart contract to get the group public key from the consortium blockchain and an image block , and computes and outputs a signature for the image block .
Verify: given a group public key , an image block , and a group signature . A verifier first computes , , , , and with formula (1)–(5).
Then, it checks
If equation (6) holds, then the given image block is signed by one of these users in the group. Otherwise, it is not.
Open: this algorithm is used for recover any malicious user’s identity based their signatures. It takes as input a group public key and the corresponding private keys, ’s and ’s , together with a message and a signature . It follows the following steps to execute. Firstly, verify that is a valid signature on . Second, consider the first three elements as a linear encryption. Third, computes and then sends to via the secure channel. recovers the user’s identity as , and vice versa. At last, looks up the user index corresponding to the identity recovered from the signature.
4.3. Security Analysis of ESGS
As described above, our enhanced short group signature scheme inherits from the traditional short group signature scheme BBS04. Both of them are composed of four algorithms, namely, , , , and . More specifically, the first three algorithms remain the same in our scheme and BBS04 scheme, so their security has been proved by BBS04. As for the algorithm, we enhance its security through utilizing multiple group managers ( and ) to replace the only one group manager of the BBS04. Suppose that these two are honest-and-curious and noncolluding. Compared to the original algorithm in BBS04, in order to successfully recover user’s identity, and , must work together to reveal the malicious user’s identity. Moreover, none of them have the ability to recover the malicious user’s identity. Now, the security of the algorithm of ESGS can be proved as follows.
Theorem 1. For any adversary who has the private key of one of the two (i.e., ’s private key ), we can create a simulator which has the ability to construct parameters using the same methods as the ESGS based on a DDH (Decisional Diffie–Hellman) triple. Afterward, the simulator sends parameters to the adversary; if he/she can calculate the identity of the user, then it means that the simulator has the ability to solve the DDH problem.
Simulator: there are two main operations which should be completed by the simulator. One of them is to construct DDH triple, the other is to generate simulated parameters for the adversary based on the methods of the ESGS. The details are shown below:(i)DDH triple: consider a (multiplicative) cyclic group of order , with generator . The DDH assumption states that, given and for randomly chosen , find and make . So, the DDH triple is .(ii)Simulated parameters: construct two (multiplicative) cyclic group and ; their prime order is , is a generator of and is a generator of , and is a computable map . Select , and set such that . Select . Moreover, construct the first three elements , , and of a user’s ESGS signature and make , , and . Until now, the simulator constructs the simulated parameters and then sends it to the adversary.
Proof. When the adversary receives the simulated parameters , he or she follows the algorithm to calculate the user’s identity , and the calculation process is as follows:Based on the algorithm of the ESGS, we know that . In addition, in the DDH assumption, has the same property and . So, he/she can get the following equation:Therefore, with the advantage of knowing ’s private key , the adversary needs to find and makes so that he could get the correct identity . This means that the simulator has the same probability of being able to solve the DDH problem, but it is computationally infeasible.
Above all, we can see that algorithm is secure in the case that the attacker knows a private key of one of the two .
5. Protocol Design
Using the Ethereum, a consortium blockchain with the smart contract, an IPFS system, and the enhanced short group signature, we now construct our proposed protocol, which is the foundation of a fair and privacy-preserving image trading system. Within this protocol, the seller and the buyer can complete image transactions fairly and without worrying about privacy disclosure, including identity privacy, transaction linkability, and image preferences. Meanwhile, in each transaction, the seller and the buyer can verify the authenticity of each other’s identity through mechanism and integrity of the transaction data under privacy protection.
In order to describe briefly and clearly, we divide this protocol into four stages, including preparation stage, transaction stage, complaint stage, and revelation stage. Details of each stage are shown below.
5.1. Preparation Stage
As we mentioned in Section 3, the committee consists of three members, who are denoted by , , and . needs to generate initialization parameters and group public key of ESGS and store the secret parameter which is used to generate private key for every user. Additionally, and , respectively, generate private key and based on the received parameter from . In particular, when the committee receives multiple complaints about a specific user, and work together to recover this user based on previous signatures, open his/her identity, and add it to the blacklist. It is required that and jointly disclose the users identity using and ; this protocol ensures that any individual on the committee does not have the ability to reveal identity of any user. The detailed process is shown in Figure 3.
During this phase, three preparatory tasks need to be completed. Let denotes group signature public key, and denote the seller’s private key and buyer’s private key, respectively, denotes the joint Ethereum account of the committee members, denotes the buyer’s Ethereum account, and denotes the seller’s Ethereum account.(i)Registering Ethereum address: in order to complete the cryptocurrency exchange, the buyer, the seller, and the committee are required to register the Ethereum account which is represented by the Ethereum address. Especially, the committee’s Ethereum account is jointly generated by the committee members based on the outstanding work of [22]. Because the committee’s Ethereum account is used to store the transaction deposits of users, this mechanism can ensure that the deposits can only be handled with the consent of all committee members.(ii)Generating public and private keys of ESGS: generates group public key and issues private key for user . In addition, he or she invokes the smart contract to upload to the consortium blockchain, so users can get it to verify each other’s signature on the transaction data. When a seller applies for his/her private key from , generates private key with the secret parameter and sends to the seller. For the buyer , the same approach is used to generate the private key . Specially, , , and , where is the total user number of the group.(iii)Generating and sharing thumbnails: the seller generates thumbnails for all the photos for sale based on the Android function [23] and then uploads them to the IPFS. The buyer’s application automatically downloads thumbnails from the IPFS, so the buyer can view them anytime and decide whether to buy.
5.2. Transaction Stage
This stage is very important in the entire protocol because it can help users (buyers and sellers) transact images in a fair and privacy-preserved way. As shown in Figure 4, the transaction procedures are completed by four entities, the buyer, the seller, the smart contract, and the committee’s Ethereum account . Among these entities, there are three kinds of data exchange channels, as shown in the Notes in Figure 4. The first one is called offchain secure channel, which is used to transfer data between the buyer and seller via the peer-to-peer secure channel, such as buyer’s purchase message and seller’s encrypted image blocks and the signature. The second is presented by consortium blockchain, which means the buyer and seller exchange transaction data with the smart contract deployed on the consortium blockchain. Ethereum are the last one, which denotes that deposit is transferred among the buyer, the seller, and the committee.
During this stage, Let denote the th leaf node of Merkle tree (, where is the total number of leaf nodes), denote the Merkle proof of the leaf node based on Algorithm 2 described in Section 2, denote the encryption key of image blocks which is generated by the seller, denote the set of encrypted image blocks and the signature, denote the root hash of the Merkle tree, and denote the transaction deposit.
Now, we discuss the details of the transaction stage. We suppose that the buyer selects a satisfying image via their smart device and then initiates a purchase request to the seller via offchain secure channel.
Once the seller receives the purchase request, he or she begins to compute the Merkle tree of the traded image, generates the encryption key , and calculates the th encrypted image block and it proof , . Each encrypted image block can be independently verified with Algorithm 3 mentioned in Section 2. Afterward, the seller’s private key is used to sign for every encrypted image block, and then, they are packed as a set . Lastly, the seller sends the set and his or her Ethereum addresses to the buyer. Simultaneously, the seller sends the Merkle tree root hash of the traded image to the smart contract.
After the buyer receives and via the offchain secure channel, he/she invokes the smart contract to get the group public key and uses it to verify the signature of each encrypted image block. If verification passes, the buyer transfers the deposit to the committee’s Ethereum address and notifies the smart contract and the seller. Additionally, the seller can confirm this notification by viewing the transaction history of because of the transparency property of the Ethereum. If it does not, the transaction will be terminated.
After the seller confirms that the buyer has stored deposit in , he or she reveals the secret key to the smart contract. The buyer gets it from the smart contract and uses it to decode encrypted image blocks stored in . So, the buyer can get a new set that consists of . The buyer next verifies the integrity of each image block via Algorithm 3. If the result is correct, the buyer notifies the seller, smart contract, and , after the deadline, the committee transfers the deposit to the seller’s Ethereum address . Otherwise, the protocol moves to the complaint stage.
As described above, we use the Merkle tree to construct the block-verifiable image blocks. Now, we will depict how to use this technology.
Suppose the seller has an image, as shown in Figure 5(a), he or she pursues the following steps to build the Mekle Tree for this image. When the seller receives the transaction request, he or she divides the image into blocks, such as 4 blocks in this example. Then, the hash value of each block is used as a leaf node of the Merkle tree, such as , , , and . Whereas every nonleaf node is labelled with the cryptographic hash of its child nodes, for example, is the hash value of and . Eventually, the root hash will be computed which is mentioned in Figure 4. As a result, the image data blocks with self-verification capability are constructed successfully, and each one is composed of the leaf node image block and its proof , . Finally, the seller encodes the self-verifiable image data blocks with the secret key and signs on them with the seller’s private key. Until now, the set is constructed completely; then, the seller sends it to the buyer.
After the set , , is received by the seller through the offchain secure channel. Through signature verification and decryption described in Figure 4, the buyer can get self-verifiable image blocks, which are shown on the left side of Figure 5(b). In order to close the transaction, the integrity of each block should be verified carefully. For example, when is verified, the buyer should firstly compute a new hash based on and combine it with to generate a new hash . Finally, the buyer can link and to compute a new root hash . If is equal to the original root hash originally uploaded to the smart contract by seller, this means there is no problem with . Otherwise, the buyer should launch the complaint process. It is noticed that only if all the data blocks (such as ) pass the verification, the buyer can confirm that the traded image is fine and stitch image blocks into a complete image, and the transaction will be completed properly.
5.3. Complaint Stage
At the complaint stage, the smart contract acts as a self-executing arbiter, based on the data submitted by the buyer, to determine whether the seller has misbehavior. If yes, it refunds the deposit to the buyer. Otherwise, it transfers the deposit to the seller. Additionally, in order to allow enough complaint time for users and further ensure the fairness of the transaction, we set an expiration date for the complaint operation, such as two days or three days. Therefore, the user should launch the complaint operation before the deadline.
When the buyer launches the complaint, as shown in Figure 6, he/she needs to send the encrypted image blocks with failed integrity verification and the corresponding signature to the smart contract. This mechanism can effectively reduce the computational overhead of smart contract because the buyer only needs to submit the problematic encrypted image blocks, rather than all of encrypted image blocks. To describe clearly, we assume that the does not pass the validation, so the buyer should send , to the smart contract.
The next issue is that the smart contract should double-check the buyer’s submitted encrypted image block which is sent by the seller via offchain secure channel. Therefore, the smart contract should verify the signature firstly, then verify the integrity of , and output the verification result lastly. The details of the above procedure are shown below.(i)Verifying signature: the group public key is used to verify the correctness of . If yes, this means that the complaint request message , came from the seller and has not been tampered by the buyer; if no, it means the seller has misbehavior; the committee is notified by smart contract to transfer the deposit to the buyer after the expiration date.(ii)Verifying encrypted image block(s): the verification method described in Figure 5(b) is used again. The new hash value of is computed; then, the new is calculated based on the connected and . The smart contract computes the new root hash of the connection of and and then compares with primitively coming from the seller. If the result is equal, it proves that the seller is honest, so the smart contract notifies the committee to transfer the deposit to the seller after expiration. Otherwise, it means that the seller has misbehaviour, and should be refunded to the buyer after expiry.
During this stage, in order to reduce the computation cost of smart contract, the protocol divides a traded image into blocks and the number of blocks is decided by the seller. The self-verification image block can be constructed using the Merkle tree, and these self-verification image blocks are encrypted with the secret key and signed by the seller’s private key . As a result, when the buyer finds a self-verification image block is wrong, he/she immediately initiates a complaint request to the smart contract. The smart contract just needs to verify this submitted image block(s), not the entire image, which can greatly reduce the volume of computation required for the smart contract and improve the efficiency of smart contract validation.
5.4. Revelation Stage
The main role of this phase is to trace and open the malicious user’s identity because it is possible that there are some corrupt users who want to cheat their counterparties. For example, the seller tries to deceive the buyer with unreal images and the buyer does not want to pay after they received real images.
However, based on the properties of the complaint stage, the committee can identify malicious users. For maintaining the user-friendliness of the proposed protocol while resisting user’s misbehavior, the committee keeps periodic statistics on the malicious behavior of each user and sets thresholds for misbehavior. If a user’s malicious behavior exceeds the threshold during the period, like three times per week, the committee will reveal his or her identity. For example, if a seller sells fake images three times in a week, then and will work together to recover his or her identity for punitive purposes.
We follow the algorithm of the ESGS described in Figure 2 to construct the revelation subprotocol. In this algorithm, and , respectively, holds the private key and , which are used to jointly reveal the identity of the user. Hence, the revealing procedure is different from the algorithm of the BBS04, but they have the same security capabilities that have been proved in Section 4. Details of the revelation protocol are shown below. The two get the group public key from the consortium blockchain and obtain the encrypted image block(s) and its signature from the complained buyer. The proceeds are as follows. First, both of the verify whether is a valid signature on . If this is the case, calculates and sends it to . Then, considers the first three elements of as a linear encryption and recovers the user’s as . At last, looks up the user index corresponding to the identity recovered from the signature.
6. Security and Privacy Analysis
In this section, we present an analysis of the proposed protocol to show that it effectively addresses the fairness and privacy threats described in Section 3.3.
6.1. Fairness Analysis
As mentioned in Section 3.3, there are three kinds of threats that can threaten the fairness of the protocol. Now, let us discuss how the protocol addresses these threats.
For Threat1, the seller has no ability to cheat the buyer with the unreal images. This is guaranteed due to the transparency property of blockchain and the image block authenticity verification property of the Merkle tree. Particularly, when a buyer wants to buy a special image from the seller, he or she needs to initiate a purchase request and send it to the seller; then, the seller begins to divide the traded image into blocks and calculate the Merkle tree and invokes the smart contract to upload the Merkle tree root hash of the traded image to the consortium blockchain. Based on the transparency property of blockchain, all users (including the buyer) can view and download the root hash from the consortium blockchain; this mechanism guarantees that the root hash of the traded image cannot be modified once it is stored in one of the blocks of the consortium blockchain.
Afterward, each image block and its proof will be encrypted with a symmetric key chosen by the seller and signed with the seller’s private key. All encrypted and signed image blocks and their proofs will be packaged into a set . Then, the set and the seller’s Ethereum address is sent to the buyer via the offchain secure channel. The buyer verifies the correctness of signatures firstly using the group public key which is downloaded from the consortium blockchain platform. If the result is wrong, the transaction is terminated. Otherwise, the authenticity of the image block will be verified with its corresponding proof, and the verification method is described in Section 5.2. If any problem is found, the transaction will be terminated and the complaint will be launched by the buyer.
Additionally, the proposed protocol sets aside an expiration date for complaint operations, such as two days or three days, which can be set flexibly. The deadline gives enough time for the buyer to validate the image block. The buyer’s deposit will not be transferred to the seller until the expiration date and the buyer has not initiated a complaint operation. In conclusion, all of the above operations and mechanisms ensure that the seller has no ability to cheat the buyer with the unreal images and earns illegal income.
For Threat2, in our design, the buyer cannot refuse to pay money after receiving the real images from the seller. This is a guarantee due to the deposit prepayment mechanism and the signature forgery resistance property of group signature schemes. Especially, when the buyer receives the Merkle tree root hash of the traded image, he or she must transfer the deposit to the committee’s Ethereum address via the Ethereum blockchain. The transaction will only continue if the seller and committee recognize this transfer operation, otherwise, the transaction will be terminated.
If the transaction is successfully completed, the buyer receives the real image, the signature of the seller is valid and each image block is authentic. The deposit will be transferred to the seller’s account at the end of the expiration date. To sum up, the deposit prepayment mechanism can prevent the buyer from refusing to pay in normal image transactions.
If the buyer discovers any problem in the data sent by the seller by the deadline, he or she will initiate a complaint request to the smart contract deployed on the consortium blockchain and submit the corresponding evidence. The smart contract strictly checks whether the evidence is credible, including verifying the seller’s signature on the evidence to prevent buyers from forging evidence and verifying the authenticity and integrity of every image block to identify if the problematic image block is the same as the one reported by the buyer. Only if both of the above are met can the smart contract determine that the buyer’s complaint is valid; then, the committee’s Ethereum account will be notified to refund the deposit to the buyer; the seller informed that he or she has committed a violation in the transaction with the buyer and that the behavior will be blacklisted. In conclusion, due to the signature forgery resistance property of group signature schemes, it is very difficult for a buyer to forge the seller’s signature, so the credibility of the evidence submitted by the buyer to the smart contract can be guaranteed. Moreover, the deposit will only be returned to the buyer if the smart contract identifies the problematic image block as the same as the one reported by the buyer. As a result, the protocol can guarantee that the buyer cannot refuse to pay money after receiving the real images from the seller.
For Threat3, the group committee cannot maliciously embezzle the deposits of transactions between buyers and sellers. This is guaranteed because the committee’s Ethereum account is jointly generated and controlled by all members based on [22]. More specially, the deposits in the can only be handled with the consent of all committee members. Moreover, when developing the practical system based on the proposed protocol, the committee members come from different interests, such as user representatives, consortium blockchain operators, and regulators, so that the possibility of collusion among committee members can be minimized.
6.2. Privacy Analysis
In the proposed protocol, privacy protection means to prevent user’s identity information, user’s linkability of transactions, and even user’s image preferences from being leaked to attackers, including malicious users, intruders, and dishonest committee members. As described in Section 3.3, we next discuss how the protocol addresses these threats.
With respect to Threat4, attackers, including malicious users, intruders, and corrupt committee members, cannot detect the user’s identity information based on their signatures. This is guaranteed by reason of the full-anonymity property of [9], which proves the security of this property through defining a corresponding experiment based on the experiment CCA of [24], CPA-full-anonymity, in which the adversary cannot query the opening oracle and the security and privacy is proved slightly.
With respect to Threat5, attackers have no ability to infer the user’s linkability of transactions due to the anonymity property of the group signature. As we know, a group signature scheme is a special type of signature, each group member is able to sign message individually, but the public cannot know who signs it. In the proposed protocol, buyers and sellers sign on transaction data with their private key generated by the enhanced short group signature scheme, through consensus of miner nodes within the consortium blockchain; all transaction data will be stored in the blocks. Therefore, when malicious users, intruders, and corrupt committee members want to infer the user’s linkability of transactions based on the data stored in the consortium blockchain, for a specific transaction, they cannot identify which user signed it, so it is not feasible to infer the transaction relationship between users.
With respect to Threat6, as mentioned above, attackers cannot identify which user signs a specific transaction, so they are unable to establish the relationship between the traded images and users and thus cannot analyze user behavior, such as user’s image preference, based on image transaction history stored in the consortium blockchain. While some of the attackers may be able to analyze the transfer relationship of users’ Ethereum addresses, this is also very difficult. This is because of the following two reasons. First, a user’s Ethereum account is not related to his or her account of the consortium blockchain, and it is impossible for an attacker to correlate these two accounts of the same user. Second, all users’ transfer operations are required to go through the committee account, which is helpful to mix up the transfer relationship between users and makes analysis more difficult.
7. Evaluation
In this section, we implemented the proposed protocol by developing an experimental prototyping system and evaluated its performance in multiple dimensions. Through extensive studies and tests, we chose the Hyperledger fabric [25] as the consortium blockchain, due to the fact that it is the most widely used open-source permissioned distributed ledger technology (DLT) platform. We utilized Pairing-Based Cryptography (PBC) library [26] to implement our enhanced short group signature protocol with conditional accountability described in Section 4. The algorithms , , and are implemented based on an open-source java library [27]. In addition, the Ethereum Testnets [28] is used to support the deposit transfer among buyers, sellers, and the committee. Compared to the Ethereum Mainnet [29], the Testnets are used by protocol developers or smart contract developers to test both protocol upgrades as well as potential smart contracts in a production-like environment before deployment to Mainnet. When developers firstly apply to join the Testnets, it will give some Ether coins for testing so that developers can save money.
7.1. Prototyping Experiment
In this prototyping system, to meet user habits, we developed mobile applications for both sellers and buyers, and independent Web applications for , , and . More specifically, to prevent collusion of committee members, is set as the operator of fabric, like the association of photographers. and can be elected by all users in the system and updated regularly. The structure of the prototyping system is shown in Figure 7 and the operating environment for each component is shown in Table 1. For details about transaction procedures in the prototyping system, see Appendix A.
Mobile application: mobile application should be installed on both the buyer’s and seller’s smart devices. It is used to interact transaction data with the Hyperledger fabric, upload and download thumbnail with the IPFS, and transfer Ether with the Ethereum. In particular, this application implements thumbnail generation, upload and download preview, Merkle tree calculation, image block proof computation and verification, 128bit-AES key generation, encryption and decryption, group signature and verification, Ether transfer, etc.
Web application: web applications are mainly developed for the committee members , , and , which can make them manage the group easier and faster. For , web client primarily provides functions of ESGS parameter initialization, secret parameter generation and storage, public key generation, user’s private key generation and issuance, interaction parameters , , and with and , and visual operation. For and , the client mainly completes visual interaction, interaction with , and private key or generation and jointly responds and revealing the malicious user real identity.
Hyperledger fabric: we deployed a four-node fabric network based on its open-source code [30] v2.2 LTS release version. Every node is configured as the full node, which means it has a complete copy of the ledger. First, this mechanism can guarantee all transaction data are open and transparent to every user. Moreover, the rights of each node are the same, and the destruction of any node will not affect the security of the whole system or cause data loss. Lastly, the ledger data of each node is exactly the same, which means that data tampering of a single node is meaningless. All of these nodes communicate with each other on a peer-to-peer network.
Smart contract: the smart contract is implemented using the program language Solidity [31]. Through invoking the corresponding interface, the can upload group public key , the seller can upload root hash and 128bit-AES key , and the buyer can download , , and . Additionally, users can upload questionable encrypted image block(s) and the corresponding signature(s) to the smart contract. Once the smart contract receives this type of data, it will follow the steps of Section 5.3 to automatically determination who has misbehavior in the seller or the buyer and handle accordingly based on the result.
Ethereum Testnets: there are two kinds of accounts on the Ethereum test network. The first is the committee member co-generated account, which is used to keep deposits for users. The second is user’s account and used to send and receive Ether.
7.2. Performance Evaluation
In this section, we evaluated metrics in the ESGS modules computation cost, fabric network upload and download latency, image block encryption and decryption computation cost, and smart contract judgment cost. As shown in Table 2, after 1000 tests, we calculated the average computational overhead for to generate secret parameter , user private key and public key , to generate private key , to generate private key , the user to sign image block, the verifier to verify signature, and and to jointly recover user’s real identity. We can see that the average computational overhead of most of the modules is within milliseconds, and this means our enhanced short group signature can perfectly meet the practical requirements.
Moreover, as shown in Table 3, we calculated the maximum, minimum, and average upload and download latency of the network through 1000 tests. Similarly, the four-node fabric network can respond to the user’s uploading and downloading operations in milliseconds, with a very good user interaction experience.
In addition, in order to evaluate the encryption and decryption computation cost of image block(s) on the mobile device, as shown in Figure 8, we tested the encryption and decryption overheads for the different number of image blocks. It is noticed that the encryption time is a little longer than decryption time, but they can all be done in tens of milliseconds. To evaluate the efficiency of smart contract, as shown in Figure 9, the computation cost of smart contract for the different number of image blocks which are complained by the buyers. We can see that the smart contract has the ability to complete the judgment task in tens of milliseconds. However, along with the number of block increases, the computation overhead increases as well.
8. Related Work
Fair exchange is a well-studied research problem. It has been shown that fair exchange is not possible without further assumptions about a trusted third party [32–34]. To circumvent this impossibility, researchers have studied weaker security optimistic models, in which the third trusted party (TTP for short) is only consulted if one party deviates from the expected behavior [35, 36]. We can consider the smart contract-based solution as a variant of the optimistic protocol, where the smart contract plays the role of the TTP. In particular, KüpçüLysyanskaya [5] consider a similar use case, file sharing, but it implements very different security than what we have done. (1) The arbiter uses a cut-and-choose approach so that the probability of not finding a cheater is nonnegligible for a corrupted file. (2) The workload of the arbiter is high due to the cut-and-choose, leading to high costs in the smart contract setup. In contrast, our solution has only a negligible error rate and a small financial cost. We also emphasize that the cost models for arbitrators and smart contracts are very different.
Recently, there has been a significant amount of work on the use of cryptocurrencies such as Bitcoin and Ethereum to achieve fairness in blockchain-based protocols [6, 8, 37–39]. As already discussed, fairness is guaranteed by relying on the smart contract executed over decentralized cryptocurrencies, where the contract takes the role of an external judge that completes the exchange in case of disagreement [6]. In addition to the smart contract, perceptual hashing is leveraged to automatically detect and reject tampered images that are perceptually similar to images that are already present on the marketplace [7]. In addition, Zhao et al. designed an image network copyright transaction protection approach based on blockchain technology [8] so that the entire copyright transaction process is protected and the attribute identification of image content is identified. Unfortunately, these works only consider solving the fairness issue, while addressing the privacy issue at the same time remains to be an open problem.
Finally, we propose to build a practical image trading system that can provide a guarantee on achieving both fairness and privacy protection in an image trading system. In terms of protecting privacy, we extend a short group signature scheme [9] to protect the user’s identity, linkability of transactions, and image preference. At the same time, group signature is used in many blockchain-based social areas. Qiao utilized the group signature to prevent user’s privacy disclosure in blockchain supply chain transactions [40]. In smart grids, Chen et al. proposed a privacy-preserving scheme based on blockchain and group signature to protect users’ identities, behavior, and preferences [41]. Zhang et al. designed a scheme called BFSP, which is a fair, reliable, and privacy-preserving blockchain-based smart parking. Particularly, group signatures, bloom filters, and vector-based encryption are used to protect the user’s privacy, the smart contract is utilized to make sure fairness, and blockchain is leveraged to guarantee reliability.
9. Conclusion and Future Work
In this paper, we propose a fair and privacy-preserving image trading system based on blockchain and group signature. We extend the short group signature to our proposed system so that a verifier is able to verify a signer’s signature on transaction data, while the singer’s identity is kept private from the verifier. Moreover, the proposed protocol can protect malicious users and intruders from inferring any private information about a particular user. In addition, fairness in trading is achieved by a fair image trading protocol that is constructed by utilizing blockchain and the Merkle tree. To evaluate the efficiency of the proposal, we design and build a practical image trading system to test its multifaceted performance.
There are two interesting problems we will continue to study for our future work. One of them is the applicability of the proposed protocol to other digital goods, which means we need to analyze the characteristics of each type of digital goods and optimize our scheme according to their characteristics so that it can be both secure and practical. Another problem for our future work is to explore the feasibility of decentralized stablecoins and NFT in the proposed scheme because Ether is a nonstable cryptocurrency and its price fluctuates too much, which can cause unnecessary losses to users. Moreover, NFT [42] is a very popular new technology used for copyright validation and trading of digital artworks.
Appendix
A. Image Transaction Procedures with Screenshots
In this section, we combine transaction procedures and the screenshots of the Web applications (used by committee members) and the Android applications (used by the seller and the buyer) to depict the entire image transaction in Figure 10. Particularly, the circular icons with numbers and light red grid lines represent the specific trading steps. The text above, below, or in the upper left corner of each screenshot identifies the work completed in this step. The Ethereum Testnets is represented by the Ethereum icon.
Data Availability
No data were used to support this study.
Conflicts of Interest
The authors declare that they have no conflicts of interest.
Acknowledgments
Le Wang and Xiaodong Lin were supported by Natural Sciences and Engineering Research Council of Canada (NSERC). Xuefeng Liu was supported by the Key Research and Development Programs of Shaanxi, under Grant 2019ZDLGY13-04.