# A Fair and Privacy-Preserving Image Trading System Based on Blockchain and Group Signature

Authors: Le Wang; Xuefeng Liu; Xiaodong Lin
Journal: Security and Communication Networks
 (2021)

---

## 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.


---

## Body

## 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 Section2, 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

AMerkle 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].AMerkle tree contains leaf nodes x1,…,xn∈0,1∗, where n is an integer, is a tagged binary tree MT = Mtreex1,x2,…,xn and the ith leaf node is labelled by xi. Furthermore, a label yj of nonleaf node Yj is the hash value of the labels yjl and yjr, where yjl and yjr are labels for child nodes Yjl and Yjr, respectively (i.e., yj:=Hyjl,yjr, where H stands for hash function). We call yj the parent of yjl and yjr. We name yjl as the slibing of yjr and vice versa. A Merkle tree of n elements x1, x2, …, xn is created by Algorithm 1.Algorithm 1: Merkle tree creation.
Input: (x1,x2,…,xn)setY=root nodeifn=1thenlabelY = x1elsey0l = Mtreex1,x2,…,x⌈n/2⌉y0r = Mtreex⌈n/2⌉,…,xnlabelY = Hrooty0l‖rooty0rend ifOutput: Merkle treeMT with root YThe root node of a Merkle treeMT is labelled as rootMT. To prove that an element xi is one of leaf nodes of the Merkle tree, a Merkle proofp is used, which is a vector composed of labels on all the siblings of elements on a path from the ith leaf node to the root node. We denote Algorithm 2 for generating a Merkle proof by Merkle Tree Proof Generation, which takes a Merkle tree MT and an index i as inputs and outputs a Merkle proof p that xi is the ith leaf of MT.Algorithm 2: Merkle tree proof generation.
Input:Merkle TreeMT,indexiV=MTifork∈log2ndosetyk=labelsibling ofυsetυ=parent ofυend forOutput: Merkle Proofp=y1,…,ydAt last, the algorithmMerkle tree verification (Algorithm 3) takes as input an element xi, a Merkle proof p, and a root of Merkle tree rootMT. This algorithm is used to verify whether xi is a leaf node of the Merkle tree MT with root r using proof p. If the verification is successful, the algorithm outputs 1, otherwise, the algorithm outputs 0.Algorithm 3: Merkle tree verification.
Input:i∈n,x∈0,1λ,p=l1,…,ld,r∈0,1μfor eachlk∈p doifi/2kmod2=0thenx=Hlm‖xifHis Prgrmdlm‖xthenTerminate and Outputend ifelsex=Hx‖lkifHis Prgrmdx‖llthenTerminate and Outputend ifend ififx=rthenOutput 1elseOutput 0end if


### 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 n 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.


## 2.1. Merkle Tree

AMerkle 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].AMerkle tree contains leaf nodes x1,…,xn∈0,1∗, where n is an integer, is a tagged binary tree MT = Mtreex1,x2,…,xn and the ith leaf node is labelled by xi. Furthermore, a label yj of nonleaf node Yj is the hash value of the labels yjl and yjr, where yjl and yjr are labels for child nodes Yjl and Yjr, respectively (i.e., yj:=Hyjl,yjr, where H stands for hash function). We call yj the parent of yjl and yjr. We name yjl as the slibing of yjr and vice versa. A Merkle tree of n elements x1, x2, …, xn is created by Algorithm 1.Algorithm 1: Merkle tree creation.
Input: (x1,x2,…,xn)setY=root nodeifn=1thenlabelY = x1elsey0l = Mtreex1,x2,…,x⌈n/2⌉y0r = Mtreex⌈n/2⌉,…,xnlabelY = Hrooty0l‖rooty0rend ifOutput: Merkle treeMT with root YThe root node of a Merkle treeMT is labelled as rootMT. To prove that an element xi is one of leaf nodes of the Merkle tree, a Merkle proofp is used, which is a vector composed of labels on all the siblings of elements on a path from the ith leaf node to the root node. We denote Algorithm 2 for generating a Merkle proof by Merkle Tree Proof Generation, which takes a Merkle tree MT and an index i as inputs and outputs a Merkle proof p that xi is the ith leaf of MT.Algorithm 2: Merkle tree proof generation.
Input:Merkle TreeMT,indexiV=MTifork∈log2ndosetyk=labelsibling ofυsetυ=parent ofυend forOutput: Merkle Proofp=y1,…,ydAt last, the algorithmMerkle tree verification (Algorithm 3) takes as input an element xi, a Merkle proof p, and a root of Merkle tree rootMT. This algorithm is used to verify whether xi is a leaf node of the Merkle tree MT with root r using proof p. If the verification is successful, the algorithm outputs 1, otherwise, the algorithm outputs 0.Algorithm 3: Merkle tree verification.
Input:i∈n,x∈0,1λ,p=l1,…,ld,r∈0,1μfor eachlk∈p doifi/2kmod2=0thenx=Hlm‖xifHis Prgrmdlm‖xthenTerminate and Outputend ifelsex=Hx‖lkifHis Prgrmdx‖llthenTerminate and Outputend ifend ififx=rthenOutput 1elseOutput 0end if


## 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 n 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 Figure1, 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 r 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.Figure 1
System model.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 Section1, 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 sellersPrivacy 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


## 3.1. System Model

As illustrated in Figure1, 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 r 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.Figure 1
System model.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 Section1, 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 sellersPrivacy 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:Key Gen, Sign, Verify, and Open. In Key Gen, a committee member (named as Issuer) is responsible for generating the group public key gpk, keeping the secret parameter γ and issuing private key gski for user i. Moreover, each of the other two committee members (named as Revealer1 and Revealer2) holds a private key, ξ1 and ξ2, respectively, which are used to jointly recover malicious user’s identity. In Sign, a group member i signs the transaction data with his/her private key gski. A verifier (any group member) is able to check whether the signature of a transaction signed by a group member is correct in Verify. In Open, if a user is identified by the committee for misbehaviour, such as selling fake photos, then Revealer1 and Revealer2 work together to reveal the true identity of the user using ξ1 and ξ2. Details of this scheme are described in Figure 2.Figure 2
Details of ESGS.Consider bilinear groupsG1 and G2 with respective generators g1 and g2. Suppose further that the SDH assumption holds on (G1, G2), and the linear assumption holds on G1. The enhanced short group signature scheme employs a hash function H: 0,1∗⟶ℤp, treated as a random oracle in the proof of security. The total number of users in the group is n.KeyGen:Issuer selects h⟵RG1/1G1 and γ⟵Rℤp∗ and sets ω=g2γ. Using γ generates, for each user i, 1≤i≤n, and SDH tuple Ai,xi selects xi⟵Rℤp∗ and sets Ai⟵g11/γ+xi. At the same time, Issuer sends h to Revealer1 and Revealer2 via the secure channel. Revealer1 selects ξ1⟵Rℤp∗ and sets u∈G1 such that uξ1=h. Then, Revealer1 sends back u to Issuer via the secure channel. In a similar way, Revealer2 selects ξ2⟵Rℤp∗ and sets υ∈G1 such that υξ1=h. Then, Revealer1 sends back υ to Issuer via the secure channel. Therefore, the group public key of ESGS is gpk=g1,g2,h,u,υ,ω. The private key of Revealer1 and Revealer2 is ξ1 and ξ2, respectively. Every user’s private key is his or her tuple gski=Ai,xi. The secret parameter γ is only known to the private key Issuer.Sign: the useri holds his or her private key gski=Ai,xi, invokes the smart contract to get the group public key gpk=g1,g2,h,u,υ,ω from the consortium blockchain and an image block M∈0,1∗, and computes and outputs a signature σ=T1,T2,T3,c,sα,sβ,sx,sδ1,sδ2 for the image block M.Verify: given a group public keygpk=g1,g2,h,u,υ,ω, an image block M, and a group signature σ=T1,T2,T3,c,sα,sβ,sx,sδ1,sδ2. A verifier first computes R1, R2, R3, R4, and R5 with formula (1)–(5).(1)R1=usαT1c,(2)R2=υsβT2c,(3)R3=eT3,g2sx∗eh,ω−sα−sβ∗eh,g2−sδ1−sδ2∗eT3,ωeg1,g2C,(4)R4=T1sxusδ1,(5)R5=T2sxυsδ2.Then, it checks(6)c=?HM,T1,T2,T3,R1,R2,R3,R4,R5.If equation (6) holds, then the given image block M is signed by one of these n 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 keygpk=g1,g2,h,u,υ,ω and the corresponding private keys, Revealer1’s ξ1 and Revealer2’s ξ2, together with a message M and a signature σ=T1,T2,T3,c,sα,sβ,sx,sδ1,sδ2. It follows the following steps to execute. Firstly, verify that σ is a valid signature on M. Second, consider the first three elements T1,T2,T3 as a linear encryption. Third, Revealer1 computes λ⟵T1ξ1 and then sends λ to Revealer2 via the secure channel. Revealer2 recovers the user’s identity A as A⟵T3/λ⋅T2ξ2, and vice versa. At last, Revealer2 looks up the user index corresponding to the identity A 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,Key Gen, Sign, Verify, and Open. 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 Open algorithm, we enhance its security through utilizing multiple group managers (Revealer1 and Revealer1) to replace the only one group manager of the BBS04. Suppose that these two Revealers are honest-and-curious and noncolluding. Compared to the original Open algorithm in BBS04, in order to successfully recover user’s identity, Revealer1 and Revealer2, 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 Open algorithm of ESGS can be proved as follows.Theorem 1.
For any adversaryA who has the private key of one of the two Revealers (i.e., Revealer1’s private key ξ1), 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 A 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 groupG of order p, with generator v. The DDH assumption states that, given va and vb for randomly chosen a,b∈ℤp, find y∈G and make y=vab. So, the DDH triple is va,vb,y.(ii)
Simulated parameters: construct two (multiplicative) cyclic groupG1 and G2; their prime order is p, g1 is a generator of G1 and g2 is a generator of G2, and e is a computable map e:G1×G2⟶GT. Select h⟵RG1/1G1, and set u,v∈G1 such that h=uξ1=va. Select γ⟵Rℤp∗. Moreover, construct the first three elements T1, T2, and T3 of a user’s ESGS signature σ and make T1=uα, T2=vb, and T3=A⋅hα⋅y. Until now, the simulator constructs the simulated parameters SP=G1,G2,GT,e,u,v,h,γ,T1,T2,T3 and then sends it to the adversary.Proof.
When the adversary receives the simulated parametersSP, he or she follows the Open algorithm to calculate the user’s identity A, and the calculation process is as follows:(7)a=T3T1ξ1⋅T2ξ2=A⋅hαyuαξ1⋅vbξ2,=A⋅hαyu1ξα⋅vbξ2=A⋅hαyhα⋅vbξ2=A⋅yvbξ2.
Based on theKey Gen algorithm of the ESGS, we know that ξ2∈ℤp. In addition, in the DDH assumption, a has the same property and a∈ℤp. So, he/she can get the following equation:(8)A=A⋅yvab.
Therefore, with the advantage of knowingReleaver1’s private key ξ1, the adversary needs to find y and makes y=vab so that he could get the correct identity A. 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 thatOpen algorithm is secure in the case that the attacker knows a private key of one of the two Revealers.


## 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:Key Gen, Sign, Verify, and Open. In Key Gen, a committee member (named as Issuer) is responsible for generating the group public key gpk, keeping the secret parameter γ and issuing private key gski for user i. Moreover, each of the other two committee members (named as Revealer1 and Revealer2) holds a private key, ξ1 and ξ2, respectively, which are used to jointly recover malicious user’s identity. In Sign, a group member i signs the transaction data with his/her private key gski. A verifier (any group member) is able to check whether the signature of a transaction signed by a group member is correct in Verify. In Open, if a user is identified by the committee for misbehaviour, such as selling fake photos, then Revealer1 and Revealer2 work together to reveal the true identity of the user using ξ1 and ξ2. Details of this scheme are described in Figure 2.Figure 2
Details of ESGS.Consider bilinear groupsG1 and G2 with respective generators g1 and g2. Suppose further that the SDH assumption holds on (G1, G2), and the linear assumption holds on G1. The enhanced short group signature scheme employs a hash function H: 0,1∗⟶ℤp, treated as a random oracle in the proof of security. The total number of users in the group is n.KeyGen:Issuer selects h⟵RG1/1G1 and γ⟵Rℤp∗ and sets ω=g2γ. Using γ generates, for each user i, 1≤i≤n, and SDH tuple Ai,xi selects xi⟵Rℤp∗ and sets Ai⟵g11/γ+xi. At the same time, Issuer sends h to Revealer1 and Revealer2 via the secure channel. Revealer1 selects ξ1⟵Rℤp∗ and sets u∈G1 such that uξ1=h. Then, Revealer1 sends back u to Issuer via the secure channel. In a similar way, Revealer2 selects ξ2⟵Rℤp∗ and sets υ∈G1 such that υξ1=h. Then, Revealer1 sends back υ to Issuer via the secure channel. Therefore, the group public key of ESGS is gpk=g1,g2,h,u,υ,ω. The private key of Revealer1 and Revealer2 is ξ1 and ξ2, respectively. Every user’s private key is his or her tuple gski=Ai,xi. The secret parameter γ is only known to the private key Issuer.Sign: the useri holds his or her private key gski=Ai,xi, invokes the smart contract to get the group public key gpk=g1,g2,h,u,υ,ω from the consortium blockchain and an image block M∈0,1∗, and computes and outputs a signature σ=T1,T2,T3,c,sα,sβ,sx,sδ1,sδ2 for the image block M.Verify: given a group public keygpk=g1,g2,h,u,υ,ω, an image block M, and a group signature σ=T1,T2,T3,c,sα,sβ,sx,sδ1,sδ2. A verifier first computes R1, R2, R3, R4, and R5 with formula (1)–(5).(1)R1=usαT1c,(2)R2=υsβT2c,(3)R3=eT3,g2sx∗eh,ω−sα−sβ∗eh,g2−sδ1−sδ2∗eT3,ωeg1,g2C,(4)R4=T1sxusδ1,(5)R5=T2sxυsδ2.Then, it checks(6)c=?HM,T1,T2,T3,R1,R2,R3,R4,R5.If equation (6) holds, then the given image block M is signed by one of these n 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 keygpk=g1,g2,h,u,υ,ω and the corresponding private keys, Revealer1’s ξ1 and Revealer2’s ξ2, together with a message M and a signature σ=T1,T2,T3,c,sα,sβ,sx,sδ1,sδ2. It follows the following steps to execute. Firstly, verify that σ is a valid signature on M. Second, consider the first three elements T1,T2,T3 as a linear encryption. Third, Revealer1 computes λ⟵T1ξ1 and then sends λ to Revealer2 via the secure channel. Revealer2 recovers the user’s identity A as A⟵T3/λ⋅T2ξ2, and vice versa. At last, Revealer2 looks up the user index corresponding to the identity A 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,Key Gen, Sign, Verify, and Open. 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 Open algorithm, we enhance its security through utilizing multiple group managers (Revealer1 and Revealer1) to replace the only one group manager of the BBS04. Suppose that these two Revealers are honest-and-curious and noncolluding. Compared to the original Open algorithm in BBS04, in order to successfully recover user’s identity, Revealer1 and Revealer2, 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 Open algorithm of ESGS can be proved as follows.Theorem 1.
For any adversaryA who has the private key of one of the two Revealers (i.e., Revealer1’s private key ξ1), 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 A 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 groupG of order p, with generator v. The DDH assumption states that, given va and vb for randomly chosen a,b∈ℤp, find y∈G and make y=vab. So, the DDH triple is va,vb,y.(ii)
Simulated parameters: construct two (multiplicative) cyclic groupG1 and G2; their prime order is p, g1 is a generator of G1 and g2 is a generator of G2, and e is a computable map e:G1×G2⟶GT. Select h⟵RG1/1G1, and set u,v∈G1 such that h=uξ1=va. Select γ⟵Rℤp∗. Moreover, construct the first three elements T1, T2, and T3 of a user’s ESGS signature σ and make T1=uα, T2=vb, and T3=A⋅hα⋅y. Until now, the simulator constructs the simulated parameters SP=G1,G2,GT,e,u,v,h,γ,T1,T2,T3 and then sends it to the adversary.Proof.
When the adversary receives the simulated parametersSP, he or she follows the Open algorithm to calculate the user’s identity A, and the calculation process is as follows:(7)a=T3T1ξ1⋅T2ξ2=A⋅hαyuαξ1⋅vbξ2,=A⋅hαyu1ξα⋅vbξ2=A⋅hαyhα⋅vbξ2=A⋅yvbξ2.
Based on theKey Gen algorithm of the ESGS, we know that ξ2∈ℤp. In addition, in the DDH assumption, a has the same property and a∈ℤp. So, he/she can get the following equation:(8)A=A⋅yvab.
Therefore, with the advantage of knowingReleaver1’s private key ξ1, the adversary needs to find y and makes y=vab so that he could get the correct identity A. 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 thatOpen algorithm is secure in the case that the attacker knows a private key of one of the two Revealers.


## 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 throughSign−Verify 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 Section3, the committee consists of three members, who are denoted by Issuer, Revealer1, and Revealer2. Issuer needs to generate initialization parameters and group public key of ESGS and store the secret parameter γ which is used to generate private key gski=Ai,xi for every user. Additionally, Revealer1 and Revealer2, respectively, generate private key ξ1 and ξ2 based on the received parameter h from Issuer. In particular, when the committee receives multiple complaints about a specific user, Revealer1 and Revealer2 work together to recover this user based on previous signatures, open his/her identity, and add it to the blacklist. It is required that Revealer1 and Revealer2 jointly disclose the users identity using ξ1 and ξ2; 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.Figure 3
The details of the preparation stage.During this phase, three preparatory tasks need to be completed. Letgpk denotes group signature public key, gski and gskj denote the seller’s private key and buyer’s private key, respectively, Eth_Comm denotes the joint Ethereum account of the committee members, Eth_Buyer denotes the buyer’s Ethereum account, and Eth_Seller 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:Issuer generates group public key gpk and issues private key gskk for user k. In addition, he or she invokes the smart contract to upload gpk to the consortium blockchain, so users can get it to verify each other’s signature on the transaction data. When a seller i applies for his/her private key from Issuer, Issuer generates private key gski with the secret parameter γ and sends gski to the seller. For the buyer j, the same approach is used to generate the private key gskj. Specially, i≤n, j≤n, and i≠j, where n 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 Androidcompress 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 Figure4, the transaction procedures are completed by four entities, the buyer, the seller, the smart contract, and the committee’s Ethereum account Eth_Comm. 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 d is transferred among the buyer, the seller, and the committee.Figure 4
The details of the transaction stage.During this stage, Letimg_blockk denote the kth leaf node of Merkle tree (1≤k≤n, where n is the total number of leaf nodes), ρk denote the Merkle proof of the leaf node k based on Algorithm 2 described in Section 2, sk denote the encryption key of image blocks which is generated by the seller, S denote the set of encrypted image blocks and the signature, r denote the root hash of the Merkle tree, and d 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 keysk, and calculates the kth encrypted image block and it proof Eskimg_blockk,ρk, 1≤k≤n. Each encrypted image block can be independently verified with Algorithm 3 mentioned in Section 2. Afterward, the seller’s private key gski is used to sign for every encrypted image block, and then, they are packed as a set S. Lastly, the seller sends the set S and his or her Ethereum addresses Eth_Seller to the buyer. Simultaneously, the seller sends the Merkle tree root hash r of the traded image to the smart contract.After the buyer receivesS and Eth_Seller via the offchain secure channel, he/she invokes the smart contract to get the group public key gpk and uses it to verify the signature of each encrypted image block. If verification passes, the buyer transfers the deposit d to the committee’s Ethereum address Eth_Comm and notifies the smart contract and the seller. Additionally, the seller can confirm this notification by viewing the transaction history of Eth_Comm 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 depositd in Eth_Comm, he or she reveals the secret key sk to the smart contract. The buyer gets it from the smart contract and uses it to decode encrypted image blocks stored in S. So, the buyer can get a new set Sdecode that consists of img_blockk,ρk1≤k≤n. 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 Eth_Comm, after the deadline, the committee transfers the deposit d to the seller’s Ethereum address Eth_Seller. 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 Figure5(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 H1, H2, H3, and H4. Whereas every nonleaf node is labelled with the cryptographic hash of its child nodes, for example, H1,2 is the hash value of H1 and H2. Eventually, the root hash r 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 img_blockk and its proof ρk, 1≤k≤4. Finally, the seller encodes the self-verifiable image data blocks with the secret key sk and signs on them with the seller’s private key. Until now, the set S is constructed completely; then, the seller sends it to the buyer.Figure 5
(a) The construction method of setS and (b) the verification process of block-verifiable image blocks.After the setS=Eskimg_blockk,ρk,Siggski, 1≤k≤4, 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 block2 is verified, the buyer should firstly compute a new hash H2′ based on block2 and combine it with H1 to generate a new hash H1,2′. Finally, the buyer can link H1,2′ and H3,4 to compute a new root hash r′. If r′ is equal to the original root hash r originally uploaded to the smart contract by seller, this means there is no problem with block2. Otherwise, the buyer should launch the complaint process. It is noticed that only if all the data blocks (such as block1, block2, block3, and block4) 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 Figure6, 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 Img_block3 does not pass the validation, so the buyer should send Eskimg_block3,ρ3,Siggski, to the smart contract.Figure 6
The details of the complaint stage.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 ofimg_block3, and output the verification result lastly. The details of the above procedure are shown below.(i)
Verifying signature: the group public keygpk is used to verify the correctness of Siggski. If yes, this means that the complaint request message Eskimg_block3,ρ3,Siggski, 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 d to the buyer after the expiration date.(ii)
Verifying encrypted image block(s): the verification method described in Figure5(b) is used again. The new hash value H3′ of img_block3 is computed; then, the new H3,4′ is calculated based on the connected H3′ and H4. The smart contract computes the new root hash r′ of the connection of H3,4′ and H1,2 and then compares r′ with r 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 d to the seller after expiration. Otherwise, it means that the seller has misbehaviour, and d 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 keysk and signed by the seller’s private key gski. 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, thenRevealer1 and Revealer2 will work together to recover his or her identity for punitive purposes.We follow theOpen algorithm of the ESGS described in Figure 2 to construct the revelation subprotocol. In this algorithm, Revealer1 and Revealer2, respectively, holds the private key ξ1 and ξ2, which are used to jointly reveal the identity of the user. Hence, the revealing procedure is different from the Open 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 Revealers get the group public key gpk from the consortium blockchain and obtain the encrypted image block(s) and its signature Eskimg_blockk,ρk,Siggski from the complained buyer. The proceeds are as follows. First, both of the Revealers verify whether Siggski is a valid signature on Eskimg_blockk,ρk. If this is the case, Revealer2 calculates T2ξ2 and sends it to Revealer1. Then, Revealer1 considers the first three elements T1,T2,T3 of Siggski as a linear encryption and recovers the user’s A as A=T3/T1ξ1⋅T2ξ2. At last, Revealer1 looks up the user index corresponding to the identity A recovered from the signature.


## 5.1. Preparation Stage

As we mentioned in Section3, the committee consists of three members, who are denoted by Issuer, Revealer1, and Revealer2. Issuer needs to generate initialization parameters and group public key of ESGS and store the secret parameter γ which is used to generate private key gski=Ai,xi for every user. Additionally, Revealer1 and Revealer2, respectively, generate private key ξ1 and ξ2 based on the received parameter h from Issuer. In particular, when the committee receives multiple complaints about a specific user, Revealer1 and Revealer2 work together to recover this user based on previous signatures, open his/her identity, and add it to the blacklist. It is required that Revealer1 and Revealer2 jointly disclose the users identity using ξ1 and ξ2; 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.Figure 3
The details of the preparation stage.During this phase, three preparatory tasks need to be completed. Letgpk denotes group signature public key, gski and gskj denote the seller’s private key and buyer’s private key, respectively, Eth_Comm denotes the joint Ethereum account of the committee members, Eth_Buyer denotes the buyer’s Ethereum account, and Eth_Seller 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:Issuer generates group public key gpk and issues private key gskk for user k. In addition, he or she invokes the smart contract to upload gpk to the consortium blockchain, so users can get it to verify each other’s signature on the transaction data. When a seller i applies for his/her private key from Issuer, Issuer generates private key gski with the secret parameter γ and sends gski to the seller. For the buyer j, the same approach is used to generate the private key gskj. Specially, i≤n, j≤n, and i≠j, where n 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 Androidcompress 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 Figure4, the transaction procedures are completed by four entities, the buyer, the seller, the smart contract, and the committee’s Ethereum account Eth_Comm. 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 d is transferred among the buyer, the seller, and the committee.Figure 4
The details of the transaction stage.During this stage, Letimg_blockk denote the kth leaf node of Merkle tree (1≤k≤n, where n is the total number of leaf nodes), ρk denote the Merkle proof of the leaf node k based on Algorithm 2 described in Section 2, sk denote the encryption key of image blocks which is generated by the seller, S denote the set of encrypted image blocks and the signature, r denote the root hash of the Merkle tree, and d 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 keysk, and calculates the kth encrypted image block and it proof Eskimg_blockk,ρk, 1≤k≤n. Each encrypted image block can be independently verified with Algorithm 3 mentioned in Section 2. Afterward, the seller’s private key gski is used to sign for every encrypted image block, and then, they are packed as a set S. Lastly, the seller sends the set S and his or her Ethereum addresses Eth_Seller to the buyer. Simultaneously, the seller sends the Merkle tree root hash r of the traded image to the smart contract.After the buyer receivesS and Eth_Seller via the offchain secure channel, he/she invokes the smart contract to get the group public key gpk and uses it to verify the signature of each encrypted image block. If verification passes, the buyer transfers the deposit d to the committee’s Ethereum address Eth_Comm and notifies the smart contract and the seller. Additionally, the seller can confirm this notification by viewing the transaction history of Eth_Comm 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 depositd in Eth_Comm, he or she reveals the secret key sk to the smart contract. The buyer gets it from the smart contract and uses it to decode encrypted image blocks stored in S. So, the buyer can get a new set Sdecode that consists of img_blockk,ρk1≤k≤n. 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 Eth_Comm, after the deadline, the committee transfers the deposit d to the seller’s Ethereum address Eth_Seller. 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 Figure5(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 H1, H2, H3, and H4. Whereas every nonleaf node is labelled with the cryptographic hash of its child nodes, for example, H1,2 is the hash value of H1 and H2. Eventually, the root hash r 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 img_blockk and its proof ρk, 1≤k≤4. Finally, the seller encodes the self-verifiable image data blocks with the secret key sk and signs on them with the seller’s private key. Until now, the set S is constructed completely; then, the seller sends it to the buyer.Figure 5
(a) The construction method of setS and (b) the verification process of block-verifiable image blocks.After the setS=Eskimg_blockk,ρk,Siggski, 1≤k≤4, 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 block2 is verified, the buyer should firstly compute a new hash H2′ based on block2 and combine it with H1 to generate a new hash H1,2′. Finally, the buyer can link H1,2′ and H3,4 to compute a new root hash r′. If r′ is equal to the original root hash r originally uploaded to the smart contract by seller, this means there is no problem with block2. Otherwise, the buyer should launch the complaint process. It is noticed that only if all the data blocks (such as block1, block2, block3, and block4) 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 Figure6, 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 Img_block3 does not pass the validation, so the buyer should send Eskimg_block3,ρ3,Siggski, to the smart contract.Figure 6
The details of the complaint stage.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 ofimg_block3, and output the verification result lastly. The details of the above procedure are shown below.(i)
Verifying signature: the group public keygpk is used to verify the correctness of Siggski. If yes, this means that the complaint request message Eskimg_block3,ρ3,Siggski, 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 d to the buyer after the expiration date.(ii)
Verifying encrypted image block(s): the verification method described in Figure5(b) is used again. The new hash value H3′ of img_block3 is computed; then, the new H3,4′ is calculated based on the connected H3′ and H4. The smart contract computes the new root hash r′ of the connection of H3,4′ and H1,2 and then compares r′ with r 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 d to the seller after expiration. Otherwise, it means that the seller has misbehaviour, and d 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 keysk and signed by the seller’s private key gski. 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, thenRevealer1 and Revealer2 will work together to recover his or her identity for punitive purposes.We follow theOpen algorithm of the ESGS described in Figure 2 to construct the revelation subprotocol. In this algorithm, Revealer1 and Revealer2, respectively, holds the private key ξ1 and ξ2, which are used to jointly reveal the identity of the user. Hence, the revealing procedure is different from the Open 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 Revealers get the group public key gpk from the consortium blockchain and obtain the encrypted image block(s) and its signature Eskimg_blockk,ρk,Siggski from the complained buyer. The proceeds are as follows. First, both of the Revealers verify whether Siggski is a valid signature on Eskimg_blockk,ρk. If this is the case, Revealer2 calculates T2ξ2 and sends it to Revealer1. Then, Revealer1 considers the first three elements T1,T2,T3 of Siggski as a linear encryption and recovers the user’s A as A=T3/T1ξ1⋅T2ξ2. At last, Revealer1 looks up the user index corresponding to the identity A 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 Section3.3.


### 6.1. Fairness Analysis

As mentioned in Section3.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 hashr 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 r from the consortium blockchain; this mechanism guarantees that the root hash r 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 setS. Then, the set S and the seller’s Ethereum address Eth_Seller is sent to the buyer via the offchain secure channel. The buyer verifies the correctness of signatures firstly using the group public key gpk 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 hashr of the traded image, he or she must transfer the deposit d 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 depositd 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 d 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 accountEth_Comm is jointly generated and controlled by all members based on [22]. More specially, the deposits in the Eth_Comm 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 Section3.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.


## 6.1. Fairness Analysis

As mentioned in Section3.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 hashr 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 r from the consortium blockchain; this mechanism guarantees that the root hash r 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 setS. Then, the set S and the seller’s Ethereum address Eth_Seller is sent to the buyer via the offchain secure channel. The buyer verifies the correctness of signatures firstly using the group public key gpk 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 hashr of the traded image, he or she must transfer the deposit d 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 depositd 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 d 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 accountEth_Comm is jointly generated and controlled by all members based on [22]. More specially, the deposits in the Eth_Comm 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 Section3.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 Merkle Tree Creation, Merkle Tree Proof Generation, and Merkle Tree Verification 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 forIssuer, Revealer1, and Revealer2. More specifically, to prevent collusion of committee members, Issuer is set as the operator of fabric, like the association of photographers. Revealer1 and Revealer2 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.Figure 7
The structure of the prototyping system.Table 1
Operating environment for the demo system.
ComponentTypeCPURAM (G)Bandwidth (Mbps)BuyerAndroid smart phoneMediaTekimensity8150SellerAndroid smart phoneMediaTekimensity8150IssuerVirtual machineIntel(R)eon(R) 2 GHz41Revealer1Virtual machineIntel(R)eon(R) 2 GHz41Revealer2Virtual machineIntel(R) Xeon(R) 2 GHz41Fabric nodeVirtual machineIntel(R)Xeon(R) 2 GHz41IPFS nodeVirtual machineIntel(R) Xeon(R) 2 GHz41Mobile 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 membersIssuer, Revealer1, and Revealer2, which can make them manage the group easier and faster. For Issuer, 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 h, u, and υ with Revealer1 and Revealer2, and visual operation. For Revealer1 and Revealer2, the client mainly completes visual interaction, interaction with Issuer, and private key ξ1 or ξ2 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 Issuer can upload group public key gpk, the seller can upload root hash r and 128bit-AES key sk, and the buyer can download gpk, r, and sk. 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 Table2, after 1000 tests, we calculated the average computational overhead for Issuer to generate secret parameter γ, user private key gsk and public key gpk, Revealer1 to generate private key ξ1, Revealer2 to generate private key ξ2, the user to sign image block, the verifier to verify signature, and Revealer1 and Revealer2 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.Table 2
ESGS module performance.
γgpkξ2ξ1Average value27.878μs2.751 ms5.008 ms4.235 msgsksignverifyopenAverage value29.442μs8.091 ms7.186 ms1.796 msMoreover, as shown in Table3, 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.Table 3
Fabric network upload and download latency.
LatencyMaximum (ms)Minimum (ms)Average (ms)Upload711.00373.00511.60Download68.0033.4452.00In addition, in order to evaluate the encryption and decryption computation cost of image block(s) on the mobile device, as shown in Figure8, 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.Figure 8
Image block encryption and decryption computation cost.Figure 9
Smart contract judgment computation cost.


## 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 forIssuer, Revealer1, and Revealer2. More specifically, to prevent collusion of committee members, Issuer is set as the operator of fabric, like the association of photographers. Revealer1 and Revealer2 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.Figure 7
The structure of the prototyping system.Table 1
Operating environment for the demo system.
ComponentTypeCPURAM (G)Bandwidth (Mbps)BuyerAndroid smart phoneMediaTekimensity8150SellerAndroid smart phoneMediaTekimensity8150IssuerVirtual machineIntel(R)eon(R) 2 GHz41Revealer1Virtual machineIntel(R)eon(R) 2 GHz41Revealer2Virtual machineIntel(R) Xeon(R) 2 GHz41Fabric nodeVirtual machineIntel(R)Xeon(R) 2 GHz41IPFS nodeVirtual machineIntel(R) Xeon(R) 2 GHz41Mobile 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 membersIssuer, Revealer1, and Revealer2, which can make them manage the group easier and faster. For Issuer, 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 h, u, and υ with Revealer1 and Revealer2, and visual operation. For Revealer1 and Revealer2, the client mainly completes visual interaction, interaction with Issuer, and private key ξ1 or ξ2 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 Issuer can upload group public key gpk, the seller can upload root hash r and 128bit-AES key sk, and the buyer can download gpk, r, and sk. 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 Table2, after 1000 tests, we calculated the average computational overhead for Issuer to generate secret parameter γ, user private key gsk and public key gpk, Revealer1 to generate private key ξ1, Revealer2 to generate private key ξ2, the user to sign image block, the verifier to verify signature, and Revealer1 and Revealer2 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.Table 2
ESGS module performance.
γgpkξ2ξ1Average value27.878μs2.751 ms5.008 ms4.235 msgsksignverifyopenAverage value29.442μs8.091 ms7.186 ms1.796 msMoreover, as shown in Table3, 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.Table 3
Fabric network upload and download latency.
LatencyMaximum (ms)Minimum (ms)Average (ms)Upload711.00373.00511.60Download68.0033.4452.00In addition, in order to evaluate the encryption and decryption computation cost of image block(s) on the mobile device, as shown in Figure8, 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.Figure 8
Image block encryption and decryption computation cost.Figure 9
Smart contract judgment computation cost.


## 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.



---

*Source: 5701258-2021-10-31.xml*