Blockchain-Based Secure and Fair IoT Data Trading System with Bilateral Authorization

1  Introduction

Internet of Things (IoT) is the interconnection of physical devices, such as appliances, vehicles, and wearable devices, through the Internet. It has a number of benefits for industries and professionals. IoT devices are equipped with sensors to generate massive amounts of data. Moreover, these interconnected devices can communicate with each other and with humans, which leads to new applications and services that can improve efficiency, convenience, and quality of life [1]. The data generated by IoT devices can also be analyzed to gain insights and make informed decisions. With the development of IoT infrastructure and the rapid growth of IoT devices in recent years, we are experiencing an unprecedented surge in data.

Nowadays, there are many IoT application domains in our lives, such as healthcare, transportation, environment, and so on [2,3], and we are living in the era of the data economy. The huge volume of data collected by various IoT devices is regarded as a valuable asset. In particular, the data can be used for commercial purposes with the proliferation of machine learning solutions for artificial intelligence and big data analytics [4,5]. Such a trend requires a data marketplace [6,7] for buying and selling data, as shown in Fig. 1. However, online data trading platforms face some restrictions in trustworthiness. First of all, security and fairness are crucial challenges because online trading is carried out between non-face-to-face participants who do not fully trust each other. Therefore, it is essential to develop a secure and fair data trading platform where data can be traded between sellers and buyers in a trustworthy manner.

Figure 1: Concept of IoT data marketplace

Fair data trading implies that either the seller gets paid for the data and the buyer obtains the purchased data, or both parties fail to achieve their desired outcome. However, since online parties tend not to trust each other, it is hard to achieve a fair exchange without a trusted intermediary [8]. Hence, conventional data trading systems rely on a trusted third party (TTP) that has centralized control of the data trading platform and responsibility for recording the evidence of interactions [9,10]. However, the lack of accountability and transparency in such a centralized system are still concerns, as well as the single point of failure problem.

Blockchain is a decentralized tamper-resistant ledger technology that offers a secure and transparent way to record and verify transactions [11,12]. It functions as a distributed database where every node in the blockchain network has a copy of the ledger. Each transaction is verified and added to the blockchain through a consensus mechanism, which ensures that all nodes agree on the validity of the transaction. Once a transaction is added, it becomes immutable and cannot be altered or deleted. While commonly used to keep track of financial transactions, blockchain can be applied to a wide range of applications associated with smart contracts.

Since the advent of the blockchain, it is regarded that the role of the TTP can be replaced with the blockchain associated with smart contracts due to its reliability, transparency, and financial properties. Although the blockchain has the advantage that it can provide a decentralized platform for transparent and immutable ledgers, it has a limit on storage capacity. So, it is not viable to store bulk data on the blockchain. As an approach to this limitation, a combination of blockchain and external storage, such as the cloud, is being considered. In this approach, external storage offers a way to store and access the actual data for sale, whereas the blockchain is used to keep track of the actions taken by both the seller and the buyer during data trading.

However, in such a system model, it is required to guarantee access control and source identification for the data managed by the external storage service. Data owners (or sellers) may want to specify who can access their data entrusted to external storage as a policy. Data requesters (or buyers) may want to specify an attribute for certain data owners from whom they want to purchase data. Taking healthcare data as an example, a seller may want to provide its data only to hospitals or doctors but not insurance companies, and a buyer may want to obtain the data from men in their 20 s. This requires bilateral authorization, where the seller and the buyer must meet each other’s policies. Therefore, it is necessary to design a secure and fair data trading system that enables access control and source identification for both parties.

Regarding the fair trading protocol considered in this paper, Chen et al. proposed a blockchain-based non-repudiable IoT data trading [13], where the trading behaviors of the seller and the buyer are recorded on the blockchain to facilitate dispute resolution. However, the authors do not address the issue of secure data trading. Thereby, data confidentiality is not guaranteed, as the secret key for data decryption is published in plaintext on the blockchain. In [14], the authors introduced the idea of a secure and fair data trading system, but did not present the detailed protocol for bilateral authorization.

Inspired by [13], in this paper, we aim to enhance the protocol of Chen et al. by taking secure data trading into account from the viewpoint of access control to the data and source identification. More specifically, in order to design a bilateral authorization-enabled secure data trading system, the proposed system makes use of the identity-based matchmaking encryption (IB-ME) scheme [15]. In the proposed system, the seller specifies the attribute of the target buyer (i.e., policy) under IB-ME encryption, and the buyer specifies the attribute of the target seller under IB-ME decryption. By exploiting the security guarantee of IB-ME, the data encrypted by the seller can be decrypted only by the intended buyer. Moreover, if the decryption is correct, it implies that the seller and the buyer are both valid parties specified by the policies of each other.

To support the use of IB-ME, a trusted off-chain arbitrator also acts as the key generator for IB-ME in the proposed system. However, the role of the arbitrator differs from that of the TTP in the conventional system. In the conventional system, the TTP is responsible for managing all trading transactions as interactive evidence which will be used to make arbitration when a dispute occurs. On the other hand, because the interactions between the seller and the buyer are handled by the smart contract on the blockchain, the arbitrator is not directly involved in dealing with data trading in the proposed system, except in a disputable situation.

At this phase, it is important to note that encrypting the whole data (in the form of a large file) by using IB-ME may not be practical due to its performance. Hence, the proposed system incorporates the use of the all-or-nothing transform (AONT) [16] to input only a few transformed data blocks to IB-ME encryption while still maintaining the confidentiality of the whole data. Due to the property of AONT, it is hard to recover the original data without knowing all parts of the transformed data. In the proposed system, the seller first transforms its data by AONT and splits the transformed data into two parts, one small part and the remaining large part. Then, the seller provides the large part through external storage and publishes the small part on the blockchain in encrypted form using IB-ME. To obtain the complete data, the buyer must purchase the encrypted small part by paying the cost through the smart contract even if the buyer can access the large part from external storage. Therefore, the proposed system reduces the storage burden of the blockchain and the computations of IB-ME while maintaining the security of the data.

The contributions of this paper are summarized as follows:

•   A secure data trading system architecture based on blockchain and external storage is proposed, which enables access control by the seller and source identification by the buyer at the same time.

•   To guarantee fairness, the threats caused by a dishonest seller or buyer are classified, and a fair data trading protocol is designed with the inclusion of arbitration. The proposed protocol encourages trading parties to act with honesty by utilizing the smart contract.

•   To demonstrate the efficiency of the proposed protocol, the off-chain computation overhead and the on-chain costs are evaluated.

The rest of this paper is organized as follows: Section 2 presents encryption schemes for secure data sharing/trading and related work on blockchain-based data trading systems. System architecture and design goals considered in this paper are presented in Section 3. Cryptographic building blocks for the proposed system are presented in Section 4. The proposed secure and fair data trading protocol is designed in Section 5. Security and performance of the protocol are evaluated in Section 6. Finally, Section 7 concludes this paper.

2  Related Work

In order to implement access control for secure data sharing in IoT and cloud computing, attribute-based encryption (ABE) [17] is widely used. ABE is a promising tool that enforces receiver access control to limit access to sender data, but does not provide sender access control for source identification [18]. Access control encryption (ACE) [19] is another type of encryption that allows fine-grained control over information flow. However, ACE is more suitable for organizations with hierarchical regulation rather than IoT environments [20]. Recently, a new cryptographic primitive called matchmaking encryption (ME) was proposed [15]. ME enables the sender to specify receivers who can reveal the messages, and the receiver to determine that the received message is from the desired sender.

Research on a blockchain-based decentralized data trading model has received a great deal of attention, and several solutions for data sharing/trading in the field of the IoT industry have been introduced [21–24]. Kang et al. proposed a data trading strategy in the vehicular P2P network in which blockchain and smart contracts are adopted for secure data caching and authorized data sharing [25]. Dixit et al. proposed a decentralized platform for the digital data marketplace enabled by the blockchain, which hosts IoT data in a reliable and fault-tolerant manner [26].

With regard to secure and fair data trading, Dai et al. proposed a blockchain-based secure data trading ecosystem [27] named SDTE. In their system, the data broker conducts business with the buyer on behalf of the seller, but neither the broker nor the buyer can access the raw data owned by the seller. However, SDTE requires a special hardware security module such as Intel Software Guard Extensions (SGX). Li et al. introduced a decentralized data trading framework based on blockchain to guarantee data availability and fairness in data trading [28]. They presented two different solutions. One is to improve reliability and data availability by making use of homomorphic encryption and data sample techniques. The other is to integrate smart contract with double-authentication-preventing signatures [29] to achieve fairness during data trading.

Alsharif et al. proposed a blockchain-based medical data marketplace model [30], in which sellers enforce access control policies on the encrypted records and buyers verify the correctness of the records without revealing any information about them. In order to achieve the design goals, their model is based on ciphertext-policy attribute-based encryption (CP-ABE) [31] and zero-knowledge succinct non-interactive argument of knowledge (zk-SNARK) [32]. However, their model has the weakness that the secret value for decrypting the ciphertext is disclosed on the blockchain at the withdrawal phase.

Li et al. [33] proposed a blockchain-based secure data trading platform by using plaintext checkable encryption (PCE) [34]. Regarding transaction security and data protection, the encrypted data for sale is stored not on a blockchain but on distributed storage to alleviate the storage pressure of the blockchain. Instead, the decryption key of the data is traded on the blockchain platform. Fair exchange on this platform relies on the miners who act as arbitrators for resolving disputes and executing smart contract. However, in the event of a dispute, it causes a problem that the ciphertext and secret key are known to miners who are not trusted on the blockchain network.

The systems proposed by Alsarif et al.’s and Li et al.’s are particularly relevant to the proposed system. However, their systems only focused on the access control of the seller for data confidentiality, and also involved complex cryptographic operations with smart contracts that resulted in high computational costs on the blockchain. On the other hand, the proposed system does not involve complex cryptographic operations in on-chain procedures, but these operations are processed by each off-chain party. Table 1 briefly shows the features of the proposed system.

3  System Model

3.1 Architecture

Fig. 2 shows the data trading system architecture which consists of data owner (or seller), data requester (or buyer), arbitrator, blockchain layer, and storage layer.

•   Data Owners or Sellers (S={S1,S2,…, Sm}):

Figure 2: Overview of the proposed data trading system architecture

Each seller Si∈S advertises and offers its own data for sale through the data trading system. In order to allow only the buyer desired by the seller to access the data, Si sets the access control policy which specifies the preferable type of buyer. Then, Si publishes the trading data encrypted by using IB-ME under its access policy. For this purpose, Si needs to obtain its identity-based encryption key for IB-ME from the arbitrator.

•   Data Requesters or Buyers (B={B1,B2,…, Bn}):

A buyer Bj∈B initiates the data purchase by requesting interesting data from the system. At this phase, the buyer Bj specifies the policy required to a data seller, and then places an order with the seller Si which satisfies the policy of Bj. In order to obtain access right to the data owned by Si, Bj must be issued the decryption key under its identity from the arbitrator for IB-ME as well as pay the price of the data in accordance with the smart contract. Then, Bj gets to obtain the data if and only if the encrypted data given by Si is associated with the identity of Bj which corresponds to the access policy of Si.

•   Arbitrator (A):

The arbitrator is an off-chain entity trusted by the trading participants. If a dispute occurs, the arbitrator takes part in off-chain arbitration to resolve the dispute. It is generally assumed that the arbitrator is a neutral third party to help resolve disputes fairly and efficiently. In the proposed system, the arbitrator also acts as a key generator for IB-ME which generates an encryption key for each seller and a decryption key for each buyer, respectively.

•   Blockchain Layer:

Blockchain layer provides a trusted platform that enforces data trading rules, coordinates the data trading process, and deals with payment with digital currency. Blockchain records the result and state of the data trading protocol run between the seller and the buyer by means of transactions. Hence, the blockchain can be viewed as a recorder of evidence to prove whether the seller and the buyer comply with the data trading protocol. Smart contract defines the valid state of data trading progress and implements transaction logic to change one state to another. Seller and buyer will interact with each other by way of the blockchain client application which invokes the smart contract to perform agreed steps of the proposed data trading protocol.

•   Storage Layer:

Because blockchain is not suitable for bulk data storage, external storage services such as cloud may be adopted in the storage layer to host a huge volume of data. External storage is regarded as an untrustworthy entity, so data owners outsource their data to the storage service in the form of an encoded package for confidentiality.

In addition, to clarify the proposed system, we make the following assumptions.

•   Digital currency payment is implemented on the blockchain and each user has a digital wallet address/account with a balance.

•   The operations of the blockchain network are generic and usually understood. Each transaction submitted to the blockchain network contains the digital signature of the transaction issuer, and only confirmed transactions are included in a block appended to the blockchain.

•   The underlying blockchain platform is fault-tolerable even in the presence of malicious actors or failed components. Hence, the blockchain can act as a reliable platform and trusted third party.

3.2 Threat Model and Design Goals

Sellers and buyers who participate in online data trading are not fully trusted and may attempt to cheat each other for their own benefit. Table 2 classifies the behaviors of the seller and the buyer considered in the data trading system. Each type of honest or dishonest participant is denoted as HS, HB, DS, and DB.

A dishonest seller may attempt to charge the buyer for payment without providing the data or correct key, or may not provide the data by denying the receipt of the payment even though the buyer has paid. Moreover, in order to make unfair profits, a dishonest seller may provide wrong data that differs from what the buyer requested. On the other hand, even after taking the data, a dishonest buyer may deny receiving the data and refuse to pay for it. In addition, a dishonest buyer may deliberately ask for unfair compensation by falsely alleging that the data or key provided is incorrect, despite having received the accurate one.

Under the threat models, we take the following design goals into account for the proposed blockchain-based secure and fair data trading system.

•   Bilateral authorization and policy matching: For secure and authorized data trading, both the seller and the buyer can specify their policies that the other party must satisfy to trade the data. That is, the data trading between the seller and the buyer is achieved only if their attributes satisfy the policies specified by each other.

•   Non-repudiation and fraud prevention: The participants must carry out their responsibilities for data trading, and the transactions cannot be denied later by either of the parties involved in the data trading. Furthermore, malicious behaviors such as providing incorrect data or alleging false compensation must be prevented. In this case, no benefit should be provided to the malicious party.

•   Fair exchange: At the end of the data trading protocol, either the seller receives the payment and the buyer receives the purchased data, or neither of them receives anything. In other words, if all participants honestly behave according to the protocol, then they will receive what they want.

4  Cryptographic Building Blocks

This section briefly outlines the IB-ME [15] and the AONT [16] which serve as cryptographic building blocks of the proposed system.

4.1 Identity-Based Matchmaking Encryption

Let e :G×GT be a bililnear pairing and P be a generator of G, where G and GT be two groups of a prime order q. When we denote by snd and rcv the target identities (i.e., the access policy) respectively specified by the receiver and by the sender, IB-ME is constructed as follows.

1)   Setup (1λ): On input the security parameter 1λ, the setup algorithm chooses two random values r, s∈Zq, and sets P0=Pr. It outputs the master public key mpk = (e, G, GT, q, P, P0, H1, H2, H3, Φ) and master secret key msk = (r, s), where H1:{0,1}∗→G, H2:{0,1}∗→G, H3:GT→{0,1}l are hash functions, and Φ: {0, 1}n→{0, 1}l is a polynomial-time computable padding functioin.

2)   SKGen (mpk, msk, σ): On input the master secret key msk, and identity σ, it outputs the encryption key ekσ = H2(σ)s.

3)   RKGen (mpk, msk, ρ): On input the master secret key msk, and identity ρ, it outputs the decryption key dkρ = (dkρ1=H1(ρ)r, dkρ2=H1(ρ)s, dkρ3=H1(ρ)).

4)   Enc (mpk, ekσ, rcv, m): On input an encryption ekσ, a target identity rcv = ρ, and a message m, this algorithm proceeds as follows:

     1.   Choose two random values u, t∈Zq.

     2.   Compute T=Pt and U=Pu.

     3.   Compute kR=e(H1(ρ), P0u) and kS=e(H1(ρ), T⋅ekσ).

     4.   Compute V=Φ(m)⊕H3(kR)⊕H3(kS).

     5.   Output ciphertext C=(T, U, V).

5)   Dec (mpk, dkρ, snd, C): On input a decryption key dkρ, a target identity snd = σ, and a ciphertext C, this algorithm proceeds as follows:

     1.   Parse C as (T, U, V).

     2.   Compute kR=e(dkρ1, U) and kS=e(dkρ2,H2(σ))⋅e(dkρ3,T).

     3.   Compute Φ(m)=V⊕H3(kR)⊕H3(kS).

     4.   If the padding is valid, return m. Otherwise, return ⊥.

4.2 All-or-Nothing Transform

AONT is a randomized transformation that can be reversed, but it is difficult to do so without having knowledge of all the message blocks in the output. It can be used as input to an encryption algorithm. Encode and decode of AONT are constructed as follows.

1)   Encode (M): Let the input M be the sequence of message blocks m1, m2, . . . , mn. Encoding proceeds as follows:

     1.   Choose a random value r.

     2.   Compute ci=mi⊕G(r|i), for 1≤i≤n, where G is a cryptographically secure pseudo-random function.

     3.   Compute c0=r⊕H(c1|c2|…|cn), where H is a cryptographic hash function.

     4.   Output the encoded message (stub|package)=(c0|c1|…|cn), where stub can be set by the first a few blocks (ex., stub=c0|c1 and package=c2|…|cn).

2)   Decode (stub|package): Given the encoded message (stub|package)=(c0|c1|…|cn), decoding proceeds as follows:

     1.   Compute r=c0⊕H(c1|c2|…|cn).

     2.   Compute mi=ci⊕G(r|i), for 1≤i≤n.

     3.   Output the message M=m1|m2|…|mn.

5  Proposed System

The proposed blockchain-based secure data trading system is presented in this section. Fig. 3 shows the state transition of the proposed data trading protocol processed by the smart contract, and Table 3 describes the notations used in the protocol. Once the seller has registered its encoded data to the storage layer, the buyer can request access right to decrypt the data by invoking the order function of the smart contract. The seller will then offer the requested access right through the blockchain. If there is no order to the registered data or the requested access right is not offered within a predefined expiration time, then the smart contract will cancel the data trading process. When the data is successfully recovered with the purchased access right, the buyer confirms this data trade. Then, the seller receives the payment. However, if any fraudulent behavior occurs by either the seller or the buyer, a dispute resolution process will be initiated.

Figure 3: State transition of the proposed data trading protocols

Suppose that a seller Si wants to sell data 𝒟 and a buyer Bj wants to purchase the data owned by Si through the proposed data trading system. Si and Bj perform the data trading protocol with the mediation of the arbitrator A as described in the following sections.

5.1 Data Trading Protocol

Before describing the detailed protocol, we assume that the smart contract was deployed on the blockchain layer and the arbitrator set up its own master secret key msk and public parameters mpk by running IB-ME.Setup (1λ) algorithm as a key generator. The mpk is publicly known to the system.

5.1.1 Advertisement and Request Phase

The seller Si advertises a description of the data 𝒟 for sale attached with the policy required to buyers, and the buyer Bj searches for the data of interest and submits a request with the policy required to sellers, as follows.

1)   Si submits the advertisement transaction TXadi: = {desc𝒟, rcv, price𝒟} to the blockchain layer, where desc𝒟 is brief description about the data 𝒟, rcv is the access policy that a buyer must satisfy, and price𝒟 is the price of the data 𝒟.

2)   If Bj is interested in the data advertised by TXadi, Bj submits the request transaction TXreqj: = {TXadi.id, snd}, where TXadi.id is the identifier referenced by the request and snd is the policy specifying the attribute required to the seller.

5.1.2 Register Phase

When Si finds the request for its data, Si first encodes the data by using AONT encoding algorithm and outsources the encoded data to the storage layer. Then, Si invokes the register function of the smart contract to publish proof of the data to be traded on the system. At this phase, Si also makes a guarantee deposit that will be temporarily locked in the smart contract and confiscated if Si would act dishonestly.

1)   For data 𝒟, Si prepares AONT encoded data as (Dstub|Dpkg)← AONT.Encode (𝒟), outsources the Dpkg part to the storage layer, and then computes the hashes of the data as follows:

Δs=H(Dstub)(1)

Δp=H(Dpkg)(2)

Δs|p=Δs⊕Δp(3)

Δ=H(𝒟)(4)

2)   Si invokes the register procedure of the smart contract by submitting the transaction TXregi: = {TXreqj.id, uri, Δ, Δs|p, ΔP, depositSi, expreg}. Here, depositSi is the digital currency that the seller puts down a deposit on, uri is the link for downloading the data package from the storage, and Δ, Δs|p, ΔP are commitments of the data to be offered later.

3)   On input the register call, if the referenced TXreqj exists and Si’s account balance is sufficient for depositSi, then the smart contract sets the state as Σij = “registered” and publishes the register transaction.

Note, expreg specified in TXregi is the expiration time until when the buyer must place an order for the registered data. If the buyer does not place an order within expreg, smart contract will discard this data trading and give depositSi back to Si.

5.1.3 Order Phase

Once the encoded data is registered, Bj can download Dpkg from the storage layer. However, due to the property of AONT, Dpkg alone is not perfect to recover the actual data 𝒟, so Bj needs to order the remaining part Dstub to Si by using the smart contract.

1)   Bj downloads Dpkg from the storage linked by TXregi.uri, then computes Δp′ as follows and checks the validity of Dpkg if Δp′=?TXregi.Δp.

Δp′=H(Dpkg)(5)

2)   If Dpkg is valid (i.e., Δp′=?TXregi.Δp holds), Bj invokes the order procedure by submitting TXordj := {TXregi.id, payBj, depositBj, expord}, where payBj is the digital currency to pre-pay the price of the data but locked until the end of the protocol and depositBj is Bj’s guarantee money.

3)   On input the order call, if the current protocol state is Σij = “registered”,  TXregi.expreg is not expired and Bj’s account balance is sufficient for payBj+ depositBj, then smart contract sets the state as Σij = “ordered” and publishes the order transaction. Otherwise, the order of Bj is discarded and the state is set as Σij = “canceled”.

With regard to expord, which is the expiration time until when the seller must offer the remaining data part, if no offer is given by Si in expord then this trading will be canceled and both payBj and depositBj be returned back to Bj.

5.1.4 Offer Phase

When Si is notified that the trading state is in “ordered”, Si publishes the Dstub on the blockchain by using the smart contract so that Bj can purchase the data reliably. To provide the data in a secure manner, at this phase, Si encrypts Dstub by using IB-ME under the encryption key issued by the arbitrator and the target identity rcv representing the access policy to the buyer.

1)   The arbitrator issues Si with the encryption key as ekSi← IB-ME.SKGen (msk, attrSi) under the attrSi identifying Si’s attribute after checking if Si’s attribute satisfies the buyer’s policy snd (i.e., attrSi=snd). The key generation is off-chain process, and we assume an out-of-band secure channel.

2)   For the remaining data part Dstub, Si generates the encrypted data as Cstub← IB-ME.Enc (mpk, ekSi, rcv, Dstub).

3)   Si offers the encrypted to Bj data through the blockchain by invoking the offer procedure with TXofferi := {TXordj.id, Cstub, expoffer}.

4)   If the current state is Σij = “ordered” and TXord.expord is not expired, smart contract sets the state as Σij = “offered” and publishes the offer transaction.

5.1.5 Confirmation Phase

When the trading state is set as Σij = “offered” as a response to Bj’s order, Bj retrieves the encrypted data Cstub from the offer transaction TXofferi and reconstructs the AONT encoded data (Dstub|Dpkg) after decrypting Cstub by using IB-ME under the decryption key issued by the arbitrator and the target identity snd. If the reconstructed data is valid and the actual data 𝒟 is successfully decoded, Bj confirms this data trade.

1)   Bj retrieves Cstub from TXofferi offered by the seller.

2)   The arbitrator issues Bj with the decryption key as dkBj← IB-ME.RKGen (mpk, msk, attrBj) under the attrBj identifying Bj’s attribute after checking if attrBj satisfies seller’s policy rcv (i.e., attrBj=rcv).

3)   Bj decrypts Cstub to get the remaining data part Dstub as Dstub← IB-ME.Dec (mpk, dkBj, snd, Cstub) and combines it with Dpkg downloaded from the storage layer to construct the full AONT encoded data (Dstub|Dpkg). Bj also computes the followings, where Δ′p=H(Dpkg) is the result computed by Eq. (5) at the order phase.

Δ′s=H(Dstub)(6)

Δ′s|p=Δ′s⊕Δ′p(7)

If Δ′s|p=?TXregi.Δs|p holds, Bj recovers the actual data 𝒟 by AONT decoding the (Dstub|Dpkg) as 𝒟← AONT.Decode (Dstub|Dpkg), and if the validity of the actual data H(𝒟)=?TXregi.Δ holds then Bj invokes the confirmation procedure of the smart contract by sending TXconf: = {TXofferi.id, “ok”} to finally confirm this data trade on the blockchain.

4)   Upon receiving the confirmation call from the buyer before TXoffer.expoffer is timeout in the state Σij = ‘offered’, smart contract transfers Bj’s payment of TXordj.payBj to Si’s account, and gives back TXregi.depositSi and TXordj.depositBj to Si and Bj, respectively. The state is set as Σij = “completed” and the data trading between Si and Bj is completed normally.

5.2 Arbitration Protocols

When the seller and the buyer honestly follow the data trading protocol as described above, they can get the payment and the data, respectively. However, one party may repudiate its trading behavior or have complaints against the repudiation of the other party. Hence, an arbitration protocol to resolve such problematic situations is needed. The proposed arbitration protocols are divided into on-chain arbitration and off-chain arbitration. The former is carried out by the smart contract on the basis of the recorded proof on the blockchain, and the latter is carried out by the arbitrator when any party raises an objection to the on-chain arbitration result.

5.2.1 On-Chain Arbitration

Buyer and seller can initiate the on-chain arbitration procedure of the smart contact. From the seller’s viewpoint, when Si finds out that the buyer Bj did not confirm the data trade even though Bj had taken the data, Si invokes on-chain arbitration to get Bj’s payment. On the other hand, at the confirmation phase, when Bj finds that the digests Δ′s|p and Δ′=H(𝒟) computed by itself are not the same as Δs|p and Δ committed to the blockchain, Bj invokes on-chain arbitration by giving Δs′ and Δ′ as the evidence. On-chain arbitration is processed as follows.

1)   For Si’s on-chain arbitration call, if expoffer is expired and the state Σij is not “completed” but still in “offered”, set result = “buyer_not_confirmed” which decides that the buyer did not confirm receipt of data so the payment is not settled to the seller yet.

2)   For Bj’s on-chain arbitration call, verify the correctness of the data by computing and checking if (Δs′⊕TXregi.Δp)=?TXregi.Δs|p and Δ′=?TXregi.Δ. If the verification is fail (i.e., Δs′⊕TXregi.Δp ≠ TXregi.Δs|p or Δ′ ≠ TXregi.Δ), set the result = “seller_data_not_correct”.

3)   On the result of the above, set the state as Σij = ‘claimed’ and publish the transaction TXclaim: = {TXoffer.id, invoker, result, Δs′, Δ′, expclaim}. 

After the TXclaim is published on the blockchain, if both parties have no objections to the result and do not initiate off-chain arbitration until expclaim has passed, the smart contract finally settles the payment or gives a penalty depending on the result; transfers TXordj.payBj to Si’s account if the result is “buyer_not_confirmed”, or returns TXordj.payBj back to Bj’s account and confiscates Si’s deposit TXregi.depositSi as the penalty if the result is “seller_data_not_correct”.

5.2.2 Off-Chain Arbitration

Unfortunately, a malicious seller may give wrong data and a malicious buyer may present false evidence, which makes the on-chain arbitration lead to a wrong decision. With claiming “seller_wrong_data”, it is possible that the buyer Bj attempts to cheat the on-chain arbitration by giving intentionally forged false Δs′ and Δ′ so as to deny paying the cost even though Bj received the correct data. It is also possible that the seller Si cheats the verification by presenting wrong or useless data 𝒟′ and recording hash values derived from 𝒟′ on the blockchain from the beginning. The verification of the data by computing the hash values will be definitely passed as valid whereas the buyer receives wrong data different from what the buyer wants. On-chain arbitration is not sufficient to handle those suspicious behaviors, so data trading parties cannot help but rely on the judgment of the arbitrator.

Therefore, in such cases, Si or Bj initiates off-chain arbitration by sending TXdispute: = {TXoffer.id, Xclaim.id } to the blockchain, in which the smart contract will set the state as Σij = ‘disputed’, in order to ask for the arbitrator to resolve the dispute situation. Note, in the proposed system, the arbitrator also acts as the key generator for IB-ME. We make use of the key escrow property inherited from identity-based cryptography in order for the arbitrator to examine the traded data and the proofs recorded on the blockchain on behalf of Si and Bj. The arbitrator deals with the off-chain arbitration as follows.

1)   First, collect Dpkg from the storage and Cstub, Δ, Δs|p, ΔP, Δs′, Δ′ from the blockchain.

2)   Reconstruct the AONT encoded data (Dstub|Dpkg) after decrypting Cstub by using Bj’s escrowed IB-ME decryption key dkBj. Then, recover the data 𝒟 by decoding (Dstub|Dpkg), and compute the followings:

ΔsA=H(Dstub)(8)

ΔpA=H(Dpkg)(9)

Δs|pA=ΔsA⊕ΔpA(10)

ΔA=H(𝒟)(11)

3)   If (ΔpA, Δs|pA, ΔA) are the same as Si’s (ΔP, Δs|p, Δ) but (ΔsA, ΔA) are different from Bj’s (Δs′, Δ′), then “seller_wrong_data” of the on-chain arbitration is regarded as resulting from Bj’s forged false evidence. So, judge that Bj is malicious and set judgment = “buyer_malicious”.

4)   Even though the verification of hash-based data correctness is valid, further check the usefulness of the data. If the data 𝒟 does not meet the description desc𝒟 in TXadi, then judge that Si offered nonsense data and set judgment = “seller_malicious”.

5)   Invoke the resolve procedure of the smart contract by submitting TXresolve: = {TXdispute.id, judgment}.

It is worth noting that, in the blockchain platform, the data 𝒟 is an external item and trading the data is a real-world event. So, it is not possible for the on-chain procedure to verify the truth of data 𝒟 on its own. Therefore, in step (4), the arbitrator can judge whether the data 𝒟 actually contains useful content corresponding to the description desc𝒟 or meaningless data after looking into the data 𝒟.

Upon receiving the resolve call from the arbitrator, the smart contract processes and records the final arbitration result. If the judgment is “seller_malicious” then Si’s deposit TXregi.depositSi is confiscated as a penalty. On the other hand, if the judgment is “buyer_malicious” then Bj’s deposit TXordj.depositBj is confiscated as a penalty and TXordj.payBj is paid to Si. The resolve transaction is published on the blockchain and the protocol is completed.

6  Evaluations

6.1 Security Evaluation

As presented so far, the proposed system is based on blockchain accompanied with smart contract and makes use of IB-ME and AONT schemes. The proposed system satisfies the design goals mentioned in Section 2, assuming the security and reliability features of the underlying cryptographic primitives and blockchain.

6.1.1 Bilateral Authorization and Policy Matching

When the data is provided through external storage instead of by the data owner directly, it would be needed for the seller to specify a policy restricting access to its own data and for the buyer to specify the condition of the data provider. In the proposed data trading protocol, seller access policy rcv required for buyers and buyer policy snd required for sellers are specified in TXad and TXreq at advertisement and request phase, respectively. Data 𝒟 of the seller is first transformed to the AONT encoded data (Dstub|Dpkg) and only the Dpkg part is provided by way of the storage layer, in which it is hard to recover the data without knowing the entire. Hence, to get the actual data, the buyer has to purchase the remaining data Dstub to be given in the encrypted form by the seller.

At this phase, the data Dstub is protected by using IB-ME under the policies, snd and rcv. To perform data trading, seller and buyer have to be issued their encryption key and decryption key from the arbitrator who checks that the attributes of the seller and the buyer correspond to the policies of the other, respectively. During the protocol, the encrypted data Cstub← IB-ME.Enc (mpk, ekSi, rcv, Dstub) can be decrypted by only the buyer who has the decryption key dkBj derived from its attribute (that is, attrBj = rcv) as Dstub← IB-ME.Dec (mpk, dkBj, snd, Cstub). In addition, if the encrypted data is decrypted correctly, the buyer can be sure that the seller who has the encryption key ekSi derived from its attribute (that is, attrSi = snd) offered the data. Therefore, the data trading is achieved if and only if the seller’s policy for authorization to the data and the buyer’s policy for source identification are matched.

6.1.2 Non-Repudiation and Fraud Prevention

If the seller and the buyer honestly follow the protocol, then the data trading would be completed satisfactorily. However, the seller and the buyer are not fully trusted participants to each other, so one of them may behave maliciously as mentioned in Section 2. When the seller or the buyer attempts to cheat and repudiate trading behavior, the system must be able to detect and prevent such attempts.

Data trading transactions between seller and buyer are processed by means of the smart contract executed in compliance with the pre-defined rules, and are recorded on the tamper-resistant blockchain ledger. Transactions recorded on the blockchain at each protocol phase can be regarded as proof of the data trading between the seller and the buyer, which enables non-repudiation, and the previous protocol step must be processed before proceeding to the next step.

In the proposed system, in order to acquire the actual whole data 𝒟, the buyer must obtain the Dstub from the seller at the offer phase after pre-paying the cost payBj of the data to the smart contract at the order phase. That is, the trading proceeds according to the sequence of “ordered” → “offered” state transition. Assuming the secrecy of IB-ME and AONT schemes, the buyer can hardly recover the data 𝒟 without Dstub as discussed above. Therefore, the system can prevent DB1 type behavior because the buyer has no choice but to prepay the cost to recover the perfect data.

The system can also prevent not only DS1 type behavior but also DS2 type behavior of the seller even though the buyer prepays the cost. The prepaid payBj is locked by the smart contract until the buyer makes a confirmation by checking the correctness of the received data. After the buyer’s order transaction, if no offer is given before expord is expired, payBj is returned back to the buyer by the smart contact and the dishonest seller has nothing. Furthermore, at the confirmation phase, if the buyer received incorrect data whose hashes are not the same as the hashes recorded on the blockchain, the buyer can claim compensation for the incorrect data by invoking on-chain arbitration. Due to the collision resistance property of the cryptographic hash function, the hashes of the traded data (Δ, Δs|p, Δp) recorded on the blockchain makes the seller hard to forge a different data with the same (Δ, Δs|p, Δp). Although DS2 type seller may record both the wrong data and its hashes on the blockchain at the first place to defraud the on-chain arbitration, the wrong data cannot evade the off-chain examination by the arbitrator. So, DS2 type fraud of the seller can be handled and prevented.

Another concern, from the seller’s perspective, is the cheating of DB2 type malicious buyer that alleges false compensation. A malicious buyer may input intentionally forged evidence (Δs′≠Δs, Δ′≠Δ) for the purpose of leading the on-chain arbitration to “seller_data_not_correct” falsely. To cope with such a suspicious case, in the proposed system, the settlement on the result of on-chain arbitration is suspended for a while so that the seller can ask for the arbitrator to judge whose fraud by invoking off-chain arbitration. Then, the arbitrator collects and examines the data and the proofs, (ΔP, Δs|p, Δ) recorded by the seller and (Δs′, Δ′) by the buyer. DB2 type fraud of buyer can be detected, because the hashes computed by the arbitrator (ΔsA, ΔA) would be the same as seller’s but not as buyer’s.

6.1.3 Fair Exchange

Once again, when the seller and the buyer honestly follow the data trading protocol, then the data trading will be completed successfully. Then, the buyer will indeed get the data 𝒟, and the seller will get the payment payBj, as following the state transition “registered” → “ordered” → “offered” → “completed”. However, when the trading is canceled in the middle of the protocol run (i.e., Σij = ‘canceled’), neither the buyer’s payment nor the seller’s data is provided to them, respectively. So, both of them get nothing. In addition, due to the functionality of non-repudiation and dispute resolution described above, it is difficult for them to obtain unfair benefits by cheating each other, and penalties are even deducted if they perform the data trading protocol dishonestly.

Each party makes a guarantee deposit, depositSi and depositBj, which are locked in the smart contract until the protocol is completed. If no dispute occurs, the smart contract unlocks and returns the deposits back to each honest participant. However, if a dispute occurs, the dishonest party gets to forfeit its deposit as a penalty depending on the on-chain or the off-chain arbitration result. Eventually, the seller and the buyer will lose their guarantee money if they act maliciously during the trading protocol, which encourages both the seller and the buyer to perform the data trading honestly. Thus, the proposed system guarantees fairness so that both parties obtain what they want or gain no befit.

6.2 Performance Evaluation

The basic design principle of the proposed system is not to burden complex cryptographic operations to the smart contract as possible in order to implement lightweight on-chain procedures. Although blockchain platforms such as Ethereum support smart contract to implement complicated crypto algorithms with big-number arithmetic, the more complex operations are burdened, the more time and cost are spent. Therefore, we make the system run only basic simple operations in the on-chain procedure while rather complex cryptographic operations are processed by each off-chain local entity whose results are given to the on-chain procedure as input.

Table 4 shows the cryptographic overhead processed by each entity during the data trading protocol. In the system, the most time-consuming cryptographic scheme is IB-ME. To measure the overhead of IB-ME operations as shown in Table 5, we used the benchmark results of the Miracl cryptography library [35] implemented on Intel Core i7 3 GHz with a supersingular curve with 512-bit based field (i.e., |G| = 512 bits). So, this result shows that each entity can process the operations efficiently.

In the proposed system, the interaction between the seller and the buyer is handled by the smart contract whose procedures are triggered by the transactions submitted by the seller and the buyer. We do not restrict the underlying blockchain platform to Ethereum, but we estimate the storage overhead and the gas units consumed in Ethereum to show the cost of the proposed protocols. According to [36], it additionally costs the input data fee to the fixed initial fee of 21000 gas units to execute every transaction. With regard to the input data fee, 4 gas units per zero valued byte of data and 16 gas units per nonzero valued byte of data are paid, respectively. So, the gas costs vary depending on the input data values. Table 6 shows the data field and size used in the proposed system.

We evaluated the performance of the on-chain procedures in terms of storage overhead, gas consumption, and economic cost. We implemented the smart contract by using Solidity 0.8.7 with Remix IDE and Ethereum test network, then compared the costs of the proposed system with Alsarif et al.’s [30] and Li et al.’s [33]. The storage and the gas costs of Alsarif et al.’s and Li et al.’s are estimated by using the quantities presented in their work. Strictly speaking, it may not be appropriate to directly compare the measurements because each experiment was done separately in different environments by the authors. Nevertheless, we intend to show that the proposed system can be as efficient as others or better.

In Table 7, the gas costs are total gas units including transaction costs and code execution costs. As mentioned before, heavy cryptographic operations are not included in the proposed on-chain procedures while digital signature verification and PCE check are included in Alsarif et al.’s and Li et al.’s. Hence, the proposed system consumes less gas than others to carry out data trading even though the proposed system inputs more data. Furthermore, to show the economic expenses, we also calculated the gas price in US dollars. At the time of writing this paper, the gas price is on average 19 Gwei for 1 gas unit, 1 Gwei is 1 × 10−9 Ether, and 1 Ether is 1660 $. Therefore, the cost for the data trading in normal is about 13 × 105 gas ($ 41.002) and about 17 × 105 gas ($ 53.618) when disputed.

7  Conclusion

In today’s data-driven economy, the vast amount of data gathered by various IoT devices is regarded as a valuable asset, and this trend demands a data trading platform to sell and buy data. The emergency of the blockchain promotes the development of a decentralized trustworthy data trading platform. Therefore, in this paper, we presented a secure and fair data trading system by taking advantage of the blockchain integrated with smart contract and matchmaking encryption. The proposed system enables bilateral authorization by making use of the security features of IB-ME so that access control by the seller and source identification by the buyer are guaranteed at the same time. Moreover, we designed the fair data trading protocol incorporated with on-chain and off-chain arbitrations by leveraging the smart contract to make the parties honestly carry out the protocol. In addition, we evaluated off-chain computation overhead and on-chain costs of the proposed protocol. In comparison with existing systems relevant to our work, the proposed protocol makes it possible to implement a cost-efficient data trading system. Even though we assumed a single arbitrator, it is more desirable to adopt a decentralized arbitration system with multiple arbitrators to increase the reliability of dispute resolution. Development of a decentralized arbitration platform that allows for fair and transparent dispute resolution remains a future work.

Acknowledgement: The authors are thankful to the reviewers for their helpful comments and suggestions.

Funding Statement: This research was supported by Basic Science Research Program through the National Research Foundation of Korea (NRF) funded by the Ministry of Education (No. 2022R1I1A3063257), and supported by Electronics and Telecommunications Research Institute (ETRI) grant funded by the Korean Government [22ZR1300, Research on Intelligent Cyber Security and Trust Infra].

Conflicts of Interest: The authors declare that they have no conflicts of interest to report regarding the present study.

References

1. S. A. Ajagbe, M. O. Adigun, J. B. Awotunde, J. B. Oladosu and Y. J. Oguns, “Internet of things enabled convolutional neural networks: Applications, techniques, challenges, and prospects,” in IoT-enabled Convolutional Neural Networks: Techniques and Applications, 1st ed., New York, USA: River Publishers, pp. 27–63, 2023. [Google Scholar]

2. X. Wei, Y. Yan, S. Guo, X. Qiu and F. Qi, “Secure data sharing: Blockchain enabled data access control framework for IoT,” IEEE Internet of Things Journal, vol. 9, no. 11, pp. 8143–8153, 2021. [Google Scholar]

3. D. Koteshov, “Manufacturing Digitization: Facts, figures, and predictions,” 2019. [online] Available: https://www.elinext.com/industries/manufacturing/trends/manufacturing-facts-figures-predictions/ [Google Scholar]

4. T. Jung, X. Y. Li, W. Huang, J. Qian, L. Chen et al., “AccountTrade: Accountable protocols for big data trading against dishonest consumers,” in Proc. of the IEEE INFOCOM 2017-IEEE Conf. on Computer Communications, Atlanta, GA, USA, pp. 1–9, 2017. [Google Scholar]

5. X. Lin, J. Li, J. Wu, H. Liang and W. Yang, “Making knowledge tradable in edge-AI enabled IoT: A consortium blockchain-based efficient and incentive approach,” IEEE Transactions on Industrial Informatics, vol. 15, no. 12, pp. 6367–6378, 2019. [Google Scholar]

6. P. Banerjee and S. Ruj, “Blockchain enabled data marketplace – design and challenges,” arXiv, vol. 1811.11462, 2018. [online]. Available: https://arxiv.org/abs/1811.11462 [Google Scholar]

7. J. Christidis, P. A. Karkazis, P. Papadopoulos and H. C. Leligou, “Decentralized blockchain-based IoT data marketplaces,” Journal of Sensor and Actuator Networks, vol. 11, no. 3, pp. 1–18, 2022. [Google Scholar]

8. N. Asokan, M. Schunter and M. Waidner, “Optimistic protocols for fair exchange,” in Proc. of the 4th ACM Conf. on Computer and Communications Security, Zurich, Switzerland, pp. 7–17, 1997. [Google Scholar]

9. T. Coffey and P. Saidha, “Non-repudiation with mandatory proof of receipt,” ACM SIGCOMM Computer Communication Review, vol. 26, no. 1, pp. 6–17, 1996. [Google Scholar]

10. J. Zhou and D. Gollman, “A fair non-repudiation protocol,” in Proc. of the IEEE Symp. on Security and Privacy, Oakland, CA, USA, pp. 55–61, 1996. [Google Scholar]

11. S. Underwood, “Blockchain beyond bitcoin,” Communications of the ACM, vol. 59, no. 11, pp. 15–17, 2016. [Google Scholar]

12. S. Ruoti, B. Kaiser, A. Yerukhimovich, J. Clark and R. Cunningham, “Blockchain technology: What is it good for?” Communications of the ACM, vol. 63, no. 1, pp. 46–53, 2020. [Google Scholar]

13. F. Chen, J. Wang, C. Jiang, T. Xiang and Y. Yang, “Blockchain based non-repudiable IoT data trading: Simpler, faster, and cheaper,” in Proc. of the IEEE INFOCOM 2022 – IEEE Conf. of Computer Communications, London, United Kingdom, pp. 1958–1967, 2022. [Google Scholar]

14. M. Jeon and S. Shin, “Decntralized fair data trading with random arbitrator node,” in Proc. of the 23rd World Conf. on Information Security Applications, Jeju, South Korea, pp. 1–5, 2022. [Google Scholar]

15. G. Ateniese, D. Francati, D. Nuñez and D. Venturi, “Match me if you can: Matchmaking encryption and its applications,” Advances in Cryptology – CRYPTO 2019, Lecture Notes in Computer Science, vol. 11693, pp. 701–731, 2019. [Google Scholar]

16. R. L. Rivest, “All-or-nothing encryption and the package transform,” in Proc. of Fast Software Encryption – FSE 1997, Haifa, Israel, pp. 210–218, 1997. [Google Scholar]

17. A. Sahai and B. Waters, “Fuzzy identity-based encryption,” Advances in Cryptology-EUROCRYPT 2005, Lecture Notes in Computer Science, vol. 3494, pp. 457–473, 2005. [Google Scholar]

18. S. Xu, J. Ning, Y. Li, Y. Zhabng, G. Xu et al., “Match in my way: Fine-grained bilateral access control for secure cloud-fog computing,” IEEE Transactions on Dependable Secure Computing, vol. 19, no. 2, pp. 1064–1077, 2022. [Google Scholar]

19. I. Damgård, H. Haagh and C. Orlandi, “Access control encryption: Enforcing information flow with cryptography,” Theory of Cryptography Conference, Lecture Notes in Computer Science, vol. 9986, pp. 547–576, 2016. [Google Scholar]

20. B. Chen, T. Xiang, M. Ma, D. He and X. Liao, “CL-ME: Efficient certificateless matchmaking encryption for internet of things,” IEEE Internet of Things Journal, vol. 8, no. 19, pp. 15010–15023, 2021. [Google Scholar]

21. H. Niavis, N. Papadis, V. Reddy, H. Rao and L. Tassiulas, “A blockchain-based decentralized data sharing infrastructure for off-grid networking,” in Proc. of the 2020 IEEE Int. Conf. on Blockchain and Cryptocurrency (ICBC), Toronto, ON, Canada, pp. 1–5, 2020. [Google Scholar]

22. G. S. Ramachandran, R. Radhakrishnan and B. Krishnamachari, “Towards a decentralized data marketplace for smart cities,” in Proc. of the 2018 IEEE Int. Smart Cities Conf. (ISC2), Kansas City, MO, USA, pp. 1–8, 2018. [Google Scholar]

23. Y. Xu, P. Ahokangas, S. Yrjölä and T. Koivumaki, “The fifth archetype of electricity market: The blockchain marketplace,” Wireless Networks, vol. 27, pp. 4247–4263, 2021. [Google Scholar]

24. Y. Xu, J. Ren, G. Wang, C. Zhang, J. Yang et al., “A blockchain-based nonrepudiation network computing service scheme for industrial IoT,” IEEE Transactions on Industrial Informatics, vol. 15, no. 6, pp. 3632–3641, 2019. [Google Scholar]

25. J. Kang, R. Yu, X. Huang, M. Wu, S. Maharjan et al., “Blockchain for secure and efficient data sharing in vehicular edge computing and networks,” IEEE Internet of Things Journal, vol. 6, no. 3, pp. 4660–4670, 2018. [Google Scholar]

26. A. Dixit, A. Singh, Y. Rahulamathavan and M. Rajarajan, “FAST DATA: A fair, secure and trusted decentralized IIoT data marketplace enabled by blockchain,” IEEE Internet of Things Journal, vol. 10, no. 4, pp. 2934–2944, 2023. [Google Scholar]

27. W. Dai, C. Dai, K. K. R. Choo, C. Cui, D. Zou et al., “SDTE: A secure blockchain-based data trading ecosystem,” IEEE Transactions on Information Forensics and Security, vol. 15, pp. 725–737, 2020. [Google Scholar]

28. Y. Li, L. Li, Y. Zhao, N. Guizani, Y. Yu et al., “Toward decentralized fair data trading based on blockchain,” IEEE Network, vol. 35, no. 1, pp. 304–310, 2020. [Google Scholar]

29. B. Poettering and D. Stebila, “Double authentication preventing signatures,” International Journal of Information Security, vol. 16, no. 1, pp. 1–22, 2017. [Google Scholar]

30. A. Alsharif and M. Nabil, “A blockchain-based medical data marketplace with trustless fair exchange and access control,” in Proc. of the GLOBECOM 2020–2020 IEEE Global Communications Conf., Taipei, Taiwan, pp. 1–6, 2020. [Google Scholar]

31. J. Bethencourt, A. Sahai and B. Waters, “Ciphertext-policy attribute-based encryption,” in Proc. of 2007 IEEE Symp. on Security and Privacy (SP’07), Berkeley, CA, USA, pp. 321–334, 2007. [Google Scholar]

32. E. Ben-Sasson, A. Chiesa, E. Tromer and M. Virza, “Succinct non-interactive arguments for a von Neumann architecture,” in Proc. of the 23rd USENIX Conf. on Security Symp., Berkeley, CA, USA, pp. 781–796, 2014. [Google Scholar]

33. Y. -N. Li, X. Feng, J. Xie, H. Feng, Z. Guan et al., “A decentralized and secure blockchain platform for open fair data trading,” Concurrency and Computation: Practice and Experience, vol. 32, no. 7, pp. e5578, 2020. [Google Scholar]

34. S. Ma, Y. Mu and W. Susilo, “A generic scheme of plaintext-checkable database encryption,” Information Sciences, vol. 429, pp. 88–101, 2018. [Google Scholar]

35. MIRACL Cryptographic SDK, Available: https://github.com/miracl/MIRACL [Google Scholar]

36. G. Wood, “Ethereum: A secure decentralized generalized transaction ledger,” Berlin Version, 2022. [online] Available: https://ethereum.github.io/yellowpaper/paper.pdf [Google Scholar]