SDSM: Secure Data Sharing for Multilevel Partnerships in IoT Based Supply Chain

Abstract

Symmetric encryption algorithms enable rapid encryption of data in IoT based supply chains, which helps to alleviate the concerns of supply chain participants about privacy disclosure when sharing data. However, in supply chain management where multilevel partnerships exist universally, a pure symmetric encryption scheme cannot provide efficient data sharing and fine-grained access control. To overcome these problems, this paper proposes a secure data sharing scheme (SDSM) for IoT based supply chains by combining blockchain and ciphertext-based attribute cryptography. This scheme supports the enforcement of fine-grained access control for different levels of partnerships. In addition, to identify partnerships, we propose a metric based on the historical transaction facts on the blockchain, where the level of partnerships among participants is automatically calculated by smart contracts. Finally, we introduce personalized attributes of participants in the ciphertext-based attribute encryption algorithm to support the construction of access policies that include partnerships, allowing for more fine-grained access control. Security analyses and simulation experiments show that our proposed scheme is secure, effective, and practical.

1. Introduction

With the integration of IoT technology, supply chain management can not only improve process visibility and product traceability, but also generate large amounts of data that can be shared among partners to support critical decisions in business operations [1,2]. For privacy and data security reasons, supply chain participants are prudent in picking the recipient of shared data. In supply chains, the closeness of the partnership is often the most worthwhile criterion to consider. To reduce costs, participants often host data on third-party storage platforms (e.g., cloud storage) to share them [3,4]. Before that, participants normally employ symmetric encryption algorithms or asymmetric encryption algorithms to encrypt the data to protect their business privacy. If symmetric encryption algorithms are chosen, the keys also need to be securely distributed to each recipient of the data. This typical data sharing model suffers from several problems that cannot be ignored, such as the inability of data recipients to ensure the authenticity of the data and the low efficiency of data sharing. Therefore, how to share data hosted on third-party platforms to business partners in the supply chain in a trusted, secure, and flexible manner is a hot issue of concern for both academia and industry [5,6,7].

The emergence of blockchain technology has brought a new opportunity for supply chain data sharing. Blockchain technology provides a better solution for those transaction scenarios that require the participation of multiple parties and are difficult to establish trust because of its advantages such as distributed storage, evidence of tampering, and multi-party consensus verification of transactions. With the help of blockchain technology, supply chain management not only addresses the issue of mutual trust in data by recording transaction data authentically in the block, but also links all participants together and solves the problem of information silos [8,9,10]. All transaction records stored on the block are anchored to IoT data stored in third-party platforms through data pointers (e.g., storage address, key, signature), providing participants with a trusted data source for sharing. These trusted data require a carefully designed access policy from supply chain participants to share to the most appropriate partners. This means that participants must adopt certain methods to measure the level of partnerships [11,12]. Although blockchain brings many advantages to supply chain management, it does not solve the problem of metrics for multilevel partnerships in supply chains. It would not only significantly increase the workload of participants by having them manage a hierarchical list of partners themselves and develop access policies for shared data based on this list, but it would also be inflexible.

In order to securely and flexibly share data to one’s partners, ciphertext-based attribute encryption (CP-ABE) [13,14] has gained popularity in recent years in areas such as supply chains and medical records [15,16,17]. The central idea of the ciphertext-based attribute encryption is to represent a user’s identity as a set of attributes and then encrypt access control policies based on these attributes into the ciphertext. The encrypted data can only be decrypted if the set of identity attributes (e.g., company nationality, vendor category, etc.) of the data requester matches the access control policy. The ciphertext-based attribute encryption scheme enables a one-to-many encryption model that supports fine-grained access control of data while ensuring data security. Although the ciphertext-based attribute encryption provides sufficient flexibility, it still does not meet the needs of supply chain participants to express "partnership" when sharing data. This is because the ciphertext-based attribute encryption typically constructs access policies based on the system’s predefined set of attributes and is not good at describing the personalized attributes associated with data owners. For example, as shown in Figure 1, a product manufacturer Alice can describe the access policy of its data as “Supplier”, “USA”, “Partner Level ≥ 3”, where “Partner Level ≥ 3” is a personalized attribute closely related to Alice. This is not a situation that would be appreciated by the ciphertext-based attribute encryption.

In this paper, we incorporate blockchain technology and attribute encryption technology to propose a novel data sharing scheme for IoT based supply chain management. The scheme supports each participant in the supply chain to accomplish secure and efficient data sharing according to the level of their partnership. The main contributions of this paper are summarized as follows.

(1) We propose a secure data sharing scheme (SDSM) for multilevel partnerships in IoT based supply chains. The scheme allows supply chain participants to devise access control policies based on the level of partnerships. To the best of our knowledge, this is the first secure data sharing scheme proposed for partnerships in the supply chain.

(2) We provide a definition of multilevel partnerships based on the historical transaction records between participants and propose a method for partnership measurement.

(3) We extend the ciphertext-based attribute encryption algorithm for expressing partnerships by introducing personalized attributes of participants (or PA-CP-ABE, for short). Participants can design access policies containing partnerships through personalized attributes.

(4) We perform security and privacy analyses of the proposed scheme and implement it on the Hyperledger Fabric platform to evaluate its effectiveness and feasibility.

The rest of this paper is organized as follows. We review research work related to multilevel partnerships and data sharing in Section 2. We describe the system model and design goals in Section 3. In Section 4, we present in detail our proposed secure data sharing scheme. In Section 5, we analyze the security of the proposed scheme. In Section 6, we evaluate the performance of the scheme through simulation experiments. Finally, the concluding remarks are presented in Section 7.

2. Related Work

In this section, we review the application of IoT technologies and blockchain technologies in supply chain management and highlight some of the work related to secure partnership-based data sharing in supply chains.

IoT Based Supply Chain Management. The first opportunity that IoT technology brings to the supply chain is the application of radio frequency identification (RFID) technology. Utilizing RFID and wireless communication, supply chain management can construct a global network for automatic identification and real-time sharing of item information. Niederman et al. [18] analyzed the impact of RFID technology on supply chains in terms of technical infrastructure, application logic, business processes, and management. With the addition of IoT devices such as GPS and sensors, supply chain management can not only track the location of products or individual components, but also verify and ensure the authenticity and quality of products during production and transportation. Yang et al. [19] developed a novel RFID-based system, CDTA, which is suitable for counterfeit detection, traceability, and authentication in IoT supply chains. CDTA consists of different types of on-chip sensors and in-system structures that collect the necessary information to detect multiple counterfeit IC types (recalls, clones, etc.), track and trace IoT devices, and verify the authenticity of the entire system. Further, with the aid of cloud computing, IoT is able to automate key aspects of supply chain work, such as material collection, environmental assessment, and quality inspection, greatly simplifying the process of information processing. Misra et al. [20] discussed the role of IoT and big data analytics in agriculture, supply chain modernization, and food quality assessment, and pointed out that the food supply chain industry is at the forefront of IoT applications. The IoT brings numerous obvious benefits to the supply chain, but an important prerequisite for reaping these benefits is that the data held by the various participants can be efficiently shared among partners.

Multilevel Partnerships in Supply Chains. Partnerships can drive supply chain management capabilities by integrating internal and external resources and can be classified into different levels based on criteria such as importance, strength, and closeness. Piltan et al. [21] proposed a multi-criteria decision support model to assess the factors that influence ongoing partnerships. Rezaei et al. [22] reviewed different types of partnerships and collaboration structures among networked organizations in supply chains. Participants are at each level of the partnership network and are responsible for the overall output of the network and customer satisfaction. In this structure, supply chain partners seek to gain advantages over what each would gain individually. Kim et al. [23] examined how the use of blockchain in supply chain activities affects (increases or decreases) the efficiency and growth of supply chain partnerships and thus supply chain performance outcomes. Putra et al. [24], for cross-sectoral public-private partnerships (PPPs), proposed a protocol called Putra-Ramli Secure Cyber-incident Information Sharing (PURA-SCIS) to guarantee privacy protection. While these works explored and attempted to model multilevel partnerships, they do not give how to evaluate the level of partnerships in supply chains in practice.

Secure Data Sharing. Security is particularly important when the data to be shared involves personal or business privacy. A considerable amount of research literature has proposed different approaches to securely share data. Among these approaches, ciphertext-based attribute encryption schemes have been favored by the academic community in recent years. Qi et al. [25] proposed a scalable item-level data access control mechanism that defines and enforces access policies based on the role attributes of the participants and the RFID tag attributes of the items. To implement this mechanism, an updatable encryption scheme was designed to encapsulate the private data after attribute-based encryption. Although this encryption scheme supports item-level access control and revocation of access rights, it cannot support partnership-based hierarchical definition of access policies between upstream and downstream of the supply chain. Qi et al. [26] extended the data access control scheme in another paper to design a secure industrial data access control scheme for cloud-assisted IIoT (Industrial Internet of Things). The scheme enables participants to enforce fine-grained access control policies on their IoT data through an encryption scheme based on ciphertext policy attributes. To provide data sharing services across multiple IoT systems, Wei et al. [27] used blockchain technology to build a multicentric data management framework and designed an attribute encryption algorithm that can be used in multicentric scenarios. To improve the security and reliability of data sharing, Almagrabi et al. [28] adopted classification learning to classify the authorized resources regularly based on the trust level of available resources. Miao et al. [29] sought to protect the privacy of data providers in IoT by introducing peer-to-peer joint learning and blockchain technology to data sharing. Jia et al. [30] proposed a consensus-based distributed auction scheme for achieving privacy protection and resisting collusion attacks of shared data. Below are a few data sharing schemes with security or sensitivity levels that are most relevant to the work in this paper. Wang et al. [31] proposed an efficient hierarchical attribute encryption scheme for cloud computing files (FH-CP-ABE). This scheme integrates the hierarchical access structure into a single access structure and then uses the integrated access structure to encrypt the hierarchical files. The cryptographic components related to attributes can be shared by files. Zaghloul et al. [32] proposed a permission based multilevel organization data sharing scheme (P-MOD), which combines the permission based access structure with the attribute based encryption mechanism to handle the management and sharing of large datasets. Based on P-MOD, Zaghloul et al. further provided a hierarchical sharing scheme for medical records in [33]. In this scheme, patients are allowed to selectively share medical records based on the different levels of the staff in a hierarchical institution.

3. System Model and Problem Description

In blockchain-enabled supply chain management, the traceability of product transaction processes and the shareability of transaction data are always two very important concerns. The former can help provide the proof of product origin and the recourse for product safety incidents (e.g., fake vaccines), whereas the latter can provide benefits for decision optimization in the production process or sales execution of the involved parties. To facilitate product traceability, each product is typically assigned a code (such as an RFID code) that serves as a unique identifier for the product in offline and online transactions [18]. The participants in the supply chain associated with this product submit the transaction records to the blockchain as a non-repudiation deposit. At the same time, these transaction records link all participants together to form a traceable chain. The IoT data associated with these transaction records (e.g., location and environmental information during transportation) also hold significant business value. When it comes to sharing these data, the participants are in a dilemma. On the one hand, they expect to achieve productivity and sales efficiency by sharing data among collaborators. On the other hand, they want to ensure that the privacy of their business is not compromised to unrelated users, especially their business rivals.

Encrypting the data before sharing them seems to be a more straightforward idea, and then the participants in supply chains host the encrypted data on a third-party cloud platform (for cost reasons) [26]. We refer to the tuple $\langle C{T}_d^{addr},K_{sym}\rangle$ as a data pointer where $C{T}_d^{addr}$ is the address where the encrypted data are stored on the cloud platform, and $K_{sym}$ is the key used for encryption. What needs to be considered later is how to share these data pointers effectively to those partners that the data provider expects. Our first thought is to submit these data pointers to the blockchain in the form of transactions (named point transactions). Due to the openness of blockchain data storage, any legitimate user of the blockchain is able to extract the transaction data in the block. To solve this problem, we encrypt the data pointers once more before committing them to the blockchain. This time, the ciphertext-based attribute encryption becomes our ideal encryption scheme because it has the advantage of being encrypted once and shared by many.

In a point transaction, we often share multiple data related to the product, such as price, location information in transportation, monitoring data of the storage environment, and so on. These shared data have different sensitivities. We store them in different files, denoted by $F_i(i=1,2,\cdots ,n)$, where n is the highest sensitivity level of the file [32]. The participants sharing data expect that the files with higher sensitivities require higher levels of partnerships to access them. We use ${\mathcal{L}}_i(i=1,2,\cdots ,n)$ to denote the partnership level. The larger the value of i, the higher the partnership level.

3.1. System Model

The system model of a secure data sharing scheme (SDSM) for multilevel partnerships is shown in Figure 2. This scheme consists of six key components.

(1) Data Owner (DO). A data owner is a provider of shared data. In our supply chain management, all participants who complete product transactions in the supply chain can be considered as data owners. Before sharing data, they can request their own personalized attributes from the attribute manager and integrate these attributes into their desired access policies. We denote the set of DO as $\mathbb{DO}=\left\{D{O}_i\right|1\le i\le n\}$, where $D{O}_i$ denotes the ith data owner. We denote the set of personalized attributes as $\mathbb{PA}=\left\{P{A}_i\right|1\le i\le n\}$, where $P{A}_i$ is the personalized attribute of the $D{O}_i$; $P{A}_i$ is a multi-valued attribute, and each value corresponds to a partnership level ${\mathcal{L}}_j$. For simplicity, we specify that when $P{A}_i=x$, it denotes the xth level partnership ${\mathcal{L}}_x$.

(2) Data Requester (DR). A data requester is a visitor to the shared data provided by data owners. In our supply chain management, all supply chain participants (including possible regulators) can be data requesters. We denote the set of DR as $\mathbb{DR}=\left\{D{R}_i\right|1\le i\le n\}$, where $D{R}_i$ denotes the ith data requester. Each data requester can request a decryption private key based on his own set $\mathbb{S}=\{S_1,S_2,\cdots ,S_k\}$ of attributes. In addition to this, the data requester can apply the decryption private key by combining $\mathbb{S}$ with the personalized attribute $P{A}_i$ of the particular data owner $D{O}_i$.

(3) Attribute Authority (AA). The attribute authority is the administrator of the system attributes and is responsible for verifying the attributes for all data requesters and issuing private keys for data decryption. In our scheme, the attribute authority may also need to interact with smart contracts to evalute the partnership level of the data requester $D{R}_j$ with respect to the data owner $D{O}_i$.

(4) Smart Contract (SC). Smart contracts are used to measure partnerships between participants. In our scheme, these smart contracts are created and deployed by the system and data owners on the blockchain. In particular, the system contract provides some basic methods for measuring partnerships. The data owner’s private contract completes the grading of the partnership by invoking these basic methods. These private contracts will be invoked by the attribute authority in the future.

(5) Blockchain (BC). Blockchain provides a storage space for two kinds of transaction data and an execution environment for smart contracts. These two types of transactions include product ownership-related transactions and data sharing-related point transactions. By the point transaction, we mean the posting of data encryption pointers to the blockchain.

(6) Cloud Service Provider (CSP). The CSP provides the initial storage space for shared data and is ready to respond to data access requests from data owners and data requesters.

3.2. Design Goals

Our goal is to design an access control scheme for blockchain-enabled supply chains that supports multilevels partnerships and personalized attributes. Different data owners are able to assign access policies to their records so that only specific authorized partners in the supply chain can access them. We have identified three design requirements that a supply chain management system should support:

• Data privacy: The most basic design requirement is to prevent unauthorized participants from viewing any important information about the shared data submitted by the data owner.
• Fine-grained access control: Each data owner involved in a product transaction is able to specify an access policy for his shared data related to product transactions. The policy should be granular enough to help the data owner define an access policy based on the system’s predefined set of attributes and his own personalized attributes to accurately describe his authorized partners.
• Resistant to collusion attacks: Two or more data requesters with different attributes cannot combine their attributes to access and decrypt data for which they are not authorized by a data owner.

3.3. Security Model

In our SDSM scheme, the ciphertext-based attribute encryption algorithm is extended to support the personalized attributes of data owners (PA-CP-ABE). The extended PA-CP-ABE needs to satisfy the following security model [13].

Suppose $\mathcal{B}$ acts as the challenger and $\mathcal{A}$ acts as the adversary in the game. We present the PA-CP-ABE game as follows:

Init. Challenger $\mathcal{B}$ takes in a q-parallel BDHE challenge. Adversary $\mathcal{A}$ gives the challenge access structure $({\mathit{M}}^{\ast },{\rho }^{\ast })$ to the algorithm.

Setup. Challenger $\mathcal{B}$ runs the Setup algorithm and gives the public parameters, PK to adversary $\mathcal{A}$.

Query 1. Adversary $\mathcal{A}$ sends multiple sets of attributes $S_1,S_2,\cdots ,S_{q_1}$ to challenger $\mathcal{B}$, and these sets of attributes cannot satisfy the access policy $({\mathit{M}}^{\ast },{\rho }^{\ast })$. Challenger $\mathcal{B}$ runs the private key generation algorithm KeyGen to generate the corresponding attribute private key and sends it to adversary $\mathcal{A}$.

Challenge. Adversary $\mathcal{A}$ submits two plaintext messages $m_0$ and $m_1$ of equal length. Challenger $\mathcal{B}$ randomly selects $c\in \{0,1\}$ and encrypts $m_c$ under the attribute access policy $({\mathit{M}}^{\ast },{\rho }^{\ast })$. The generated ciphertext $C{T}^{\ast }$ is sent to adversary $\mathcal{A}$.

Query 2. Same as Query 1. Adversary $\mathcal{A}$ continues to submit key queries for a series of attribute sets $S_{q_1+1},S_{q_1+2},\cdots ,S_q$, again requiring that none of these attribute sets satisfy the access structure $({\mathit{M}}^{\ast },{\rho }^{\ast })$.

Guess. Adversary $\mathcal{A}$ outputs a guess $c^{\prime }$ of c and defines $|Pr\left[c=c^{\prime }\right]-\frac{1}{2}|$ as the advantage of adversary $\mathcal{A}$ in this game.

Definition 1

(Selective Access Structure Secure). A PA-CP-ABE algorithm is Selective Access Structure Secure if no polynomial-time adversary $\mathcal{A}$ wins the above game with the advantage $|Pr\left[c^{\prime }=c\right]-\frac{1}{2}|>\epsilon (·)$, where $\epsilon (·)$ is non-negligible function.

4. The Proposed SDSM Scheme

4.1. Definition of Multilevel Partnership

The criteria for classifying partnership levels in the supply chain were discussed in great detail in the literature [21,22]. From these works we can conclude that the number of transactions completed between supply chain participants in a given period of time is a core indicator for determining the partnership level.

In our scheme, the blockchain involves two types of transaction records: product transaction records and point transaction records. Our definition of the partnership is based on the history of blockchain product transactions. A product transaction record can be represented as a tuple $\langle p_{id},sen{d}_{id},rec{v}_{id},sign,timestamp\rangle$, where $p_{id}$ is the product identifier, $sen{d}_{id}$ is the id of the transaction initiator, $rec{v}_{id}$ is the id of the transaction recipient, $sign$ is the signature of the transaction initiator on the transaction record, and $timestamp$ is the time when the transaction is recorded on the blockchain. It should be emphasized that the initiator of a product transaction is also the data owner of a point transaction, and the recipient of a product transaction is also the data requester of a point transaction. In this paper, we assume that each participant appears at most once each as an initiator or a recipient in the chain of transactions for a product. The chain of transactions for the product $p_{id}$ is referred to as ${\mathbb{PC}}_{p_{id}}$. The index of transaction record $Tx$ in the transaction chain is denoted as $index\left(Tx\right)$.

Definition 2

(Transaction Distance). For the two transaction records $T{x}_a$ and $T{x}_b$ that successively appear in the transaction chain ${\mathbb{PC}}_{p_{id}}$ of the product $p_{id}$, the Transaction Distance between the initiator $sen{d}_{id}$ of $T{x}_a$ and the recipient $rec{v}_{id}$ of $T{x}_b$ is defined asTxD($sen{d}_{id},rec{v}_{id},p_{id})$= index ($T{x}_b$) − index ( $T{x}_a$), as shown in Figure 3. If $sen{d}_{id}$ and $rec{v}_{id}$ do not appear in the same transaction chain, we specify TxD$(sen{d}_{id},rec{v}_{id},p_{id})=\infty$.

When we are talking about the sharing of point transaction records, they can also be written as TxD$(D{O}_{id},D{R}_{id},p_{id})$. Here, $D{O}_{id}$ and $D{R}_{id}$ are the identifiers of the data owner and data requester, respectively.

Definition 3

(Multilevel Partnership). For the data owner DO and the data requester DR, if they appear in the transaction chain of a product and meet specific transaction distance constraints τ in a certain period of time in the past, we say that the DO and DR have an effective partner connection $qpc$. The total number $sum\left(qpc\right)$ of such effective partner connections is recorded as η. Here, τ is an integer interval in the form of [1,3], representing the lower and upper bounds of the transaction distance. The data owner DO divides η into multiple levels ${\eta }_i(i=0,1,\cdots ,l)$ and each level ${\eta }_i$ corresponds to a level ${\mathcal{L}}_i$ of partnerships. Multilevel Partnership is defined as $\mathcal{L}=\left\{{\mathcal{L}}_i\right|sum\left(qpc\right)\ge {\eta }_i,i=0,1,\cdots ,l\}$, where l is the highest level.

The difference between our scheme and the other two related works [31,32] is in the identification of multilevel relationships. Our multilevel partnerships are related to the data owners, whereas the ones in [31,32] are not. The literature [24] talked about public–private partnerships across organizational sectors, but did not give a specific division method.

4.2. The SDSM Construction

As shown in Figure 2, the participants of the supply chain are both data owners and data requesters. In a practical scenario, data requesters possibly also include regulators and consumers. For data storage, we employ a cloud service provider, which is an honest and curious entity. The cloud service provider and the blockchain platform jointly maintain the storage of transaction data. The shared original data are stored in the cloud platform after symmetric encryption, and the blockchain stores the data pointers. Before the data pointer is submitted to the blockchain platform (a point transaction), the data owner performs attribute encryption on the data pointer. The execution process of the whole scheme can be divided into the following major events.

(1) Register Personalized Attribute. In this paper, a personalized attribute refers to an attribute of a data requester that is associated with a particular data owner. If a supply chain participant requires a personalized attribute to provide more precise privacy protection for his transaction records when sharing transaction data, then he is allowed to request his personalized attributes from the attribute authority. For these, he first creates a smart contract $DOSC$ following the approach in Section 4.3 and deploys it on the blockchain. This smart contract is used to calculate the partnership level $\mathcal{L}$ of the data requester. Then, he sends the message $(D{O}_{id},DOS{C}_{addr},l)$ to the attribute authority, where $D{O}_{id}$ is the identifier of the DO, $DOS{C}_{addr}$ is the address of the smart contract on the blockchain, and l is the highest partnership level. The attribute authority verifies the DO’s identity and creates a multi-valued attribute for him.

(2) Encrypt Shared Data. The data owner splits the batch of data to be shared into multiple files according to the sensitivity level from low to high, $F_{s_1},F_{s_2},\dots ,F_{s_m}(0<s_1<s_2<\cdots <s_m\le l)$. For each file $F_{s_i}(i=0,1,\cdots m)$, the data owner encrypts it using a symmetric encryption algorithm as

$$C{T}_{F_{s_i}}=En{c}_{sym}(F_{s_i},K_{sy{m}_i}),$$

(1)

where $En{c}_{sym}$ is a symmetric encryption algorithm such as Advanced Encryption Algorithm (AES), and $K_{sy{m}_i}$ is the key chosen by the data owner to perform symmetric encryption of the shared data. Inspired by [32], the data owner randomly chooses the key $K_{sy{m}_m}$, and the encryption keys for other files of lower sensitivity are derived according to the following rules

$$K_{sy{m}_i}=H\left(K_{sy{m}_{i+1}}\right),$$

(2)

where H is a hash function. The advantage of this is that high-level partners can derive decryption keys for low-sensitivity level files.

Next, the data owner uploads the encrypted files $C{T}_{F_{s_i}}$ to the cloud service provider for storage, and the cloud service provider returns the storage address $C{T}_{F_{s_i}}^{addr}$ of the data to the publisher. In this way, the data owner holds a collection of addresses and key pairs $\left\{\langle C{T}_{F_{s_i}}^{addr},K_{sy{m}_i}\rangle \right|0<i\le m\}$. We can also refer to $\langle C{T}_{F_{s_i}}^{addr},K_{sy{m}_i}\rangle$ as the data pointer of the file.

(3) Publish Shared Record. For each $K_{sy{m}_i}$, the data owner engages in encryption using an attribute encryption algorithm. The data owner designs different attribute encryption policies for different levels of partners based on the system’s predefined attributes and his personalized attributes to protect his data from unauthorized access. As a limitation, in this paper, we assume that the visitors of a shared file in the same publishing have the same attributes, except for different partnership levels. This assumption is consistent with the characteristics of file sharing in the supply chain in practice. The encryption process is

$$C{T}_{K_i}=En{c}_{abe}(K_{sy{m}_i},{\rho }_i),$$

(3)

where $En{c}_{abe}$ is the encryption algorithm we defined in the scheme description, and ${\rho }_i$ is the access policy defined by the data owner. Finally, the data owner initiates a point transaction to the blockchain, storing the transaction record permanently on the blockchain. The message of the point transaction is $(\left\{\langle C{T}_{F_{s_i}}^{addr},C{T}_{K_i}\rangle \right|0<i\le m\},sig{n}_{DO},timestamp)$, where $sig{n}_{DO}$$(\left\{\langle C{T}_{K_i},C{T}_{F_{s_i}}^{addr}\rangle \right|0<i\le m\},sig{n}_{DO},timestamp)$, where $sig{n}_{DO}$ is DO’s signature on the message. We can also refer to $\langle C{T}_{F_{s_i}}^{addr},C{T}_{K_i}\rangle$ as the encrypted data pointer of the file.

(4) Apply Attribute Decryption Key. Once a data requester perceives that he can benefit from the data shared by some participant, in order to obtain the original record, he is required to apply a decryption key from the attribute authority. This decryption key is based on the attributes of the data requester, and, in our scenario, may also require the existence of some business partnership between the requester and the sharer of the data. The data requester provides a proof of his attributes to the attribute authority, as well as some personalized attributes that are of interest to him. The proof of personalized attributes does not need to be provided by the requester; it will be automatically verified by the attribute authority by invoking a smart contract. After completing the verification of the requester’s attributes, the attribute authority generates the decrypted private key $K_{abe}$.

(5) Fetch Symmetric Key. The data requester downloads the point transaction record from the blockchain and reads the attribute-encrypted portion $C{T}_{K_i}$. With the decryption private key $K_{abe}$ obtained from the attribute authority, it attempts to decrypt $C{T}_{K_i}$. If the decryption key $K_{abe}$ satisfies the access policy in $C{T}_{K_i}$, the decryption operation will finish successfully as

$$K_{sy{m}_i}=De{c}_{abe}(C{T}_{K_i},K_{abe}),$$

(4)

where $De{c}_{abe}$ is the attribute decryption function.

(6) Extract Shared Data. According to the data pointer address $C{T}_{F_{s_i}}^{addr}$, the data requester is able to download the data $C{T}_{F_{s_i}}$ from the cloud service provider. Potentially, our paper assumes that the data requester already has the data access rights granted by the cloud service provider. In the next step, the data requester achieves the decryption of the data aided by the symmetric key such that

$$F_{s_i}=De{c}_{sym}(C{T}_{F_{s_i}},K_{sy{m}_i}),$$

(5)

where $De{c}_{sym}$ is the symmetric decryption function. If $i>1$, the data requester calculates the lower-level file encryption key according to Equation (2) and decrypts it using Equation (5).

At this point, the data requester has completed the entire decryption process of the data. The supply chain participant who published the data has successfully shared his private data to this data requester.

4.3. Smart Contracts

In our proposed scheme, the blockchain is not only intended for storing the encrypted pointers to shared data, but also for computing the partnerships between data requesters and data owners. Based on the proposed concept of multilevel partnerships, we validate the partnerships by designing and deploying smart contracts. These smart contracts are divided into two types: system contracts and user contracts. System contracts are implemented to calculate the transaction distance, whereas user contracts define their own partnerships by invoking system contracts.

System Contracts. Because the calculation of the transaction distance is a standardized process, we implement it in the form of a system contract. Algorithm 1 outlines the computational function of the transaction distance. Lines 3–7 query all transactions performed after the time $startTime$ based on the product $p_{id}$. The function $\mathit{SearchTransByPid}$ will be the most time-consuming operation in this algorithm because it has to traverse all the transactions if no index exists in the historical transaction database. Lines 14–21 accomplish the function of determining the index of the location of the data owner $D{O}_{id}$ and the data requester $D{R}_{id}$ in the transaction chain. Finally, the transaction distance is calculated in line 26. In our paper, the transaction distance does not take into account the positivity and negativity.

Algorithm 1: ComputeTxD

Input:  $D{O}_{id},D{R}_{id},p_{id},startTime$/* $D{O}_{id}$: data owner id, $D{R}_{id}$: data requester id, $p_{id}$: product id and $startTime$: earliest time for transaction submission */   Output:  an integer representing the transaction distance   1 Create a product transaction list $tranList$   2 /*Search for transactions related to $pid$*/   3 $tranList=\mathit{SearchTransByPid}\left(p_{id}\right)$   4 fortranintranListdo   5   if $tran.timestamp<startTime$ then   6      $tranList.remove\left(tran\right)$   7   end   8 end   9 /*The transaction is sorted in ascending chronological order*/ 10 $tranList=\mathit{OrderTransByTime}\left(tranList\right)$ 11 $indexD{O}_{id}\leftarrow \infty$ 12 $indexD{R}_{id}\leftarrow \infty$ 13 /*Find the index of DO and DR in the transaction chain*/ 14 fortranintranListdo 15   if $tran.sen{d}_{id}==D{O}_{id}\mathbf{and}indexD{O}_{id}==\infty$ then 16      $indexD{O}_{id}=\mathit{index}\left(tran\right)$ 17   end 18   if $tran.rec{v}_{id}==D{R}_{id}\mathbf{and}indexD{R}_{id}==\infty$ then 19      $indexD{R}_{id}=\mathit{index}\left(tran\right)$ 20   end 21 end 22 /*If DO or DR does not appear in the transaction chain, ∞ is returned*/ 23 if$indexD{O}_{id}==\infty \mathbf{or}indexD{R}_{id}==\infty$then 24   return ∞ 25 end 26 $txDistance=\mathit{Math}.\mathit{abs}(indexD{O}_{id}-indexD{R}_{id})$ 27 return $txDistance$

User Contracts. In order to integrate partnerships in the data access policy, it is necessary for the data owner to design the logic for calculating the partnership level in their own smart contract. Algorithm 2 outlines the computational function of the partnership level. As we described in Definition 3, the partnership level depends on the number of products traded between the data owner and the data requester under certain constraints. Line 3 specifies the mapping relationship between the number of products traded and the partnership level. Line 6 uses the function $\mathit{SearchPidByUid}$ to query the ids of all products in which the data owner is involved in a transaction. Similar to $\mathit{SearchTransByPid}$ in Algorithm 1, this is a time-consuming operation. Lines 8–15 calculate the transaction distance between the data owner and the data requester for all products queried before and count the number of products that satisfy the transaction distance constraint range (line 12). In this process, the algorithm ComputeTxD is called. Finally, in lines 17–21, the partnership level is returned based on the counted number of products.

Algorithm 2: Evaluate Level of Partnership

Input:  $D{O}_{id},D{R}_{id},di{s}_{min},di{s}_{max},startTime$ /* $D{O}_{id}$:data owner id, $D{R}_{id}$: data requester id, $di{s}_{min}$: min transaction distance, $di{s}_{max}$: max transaction distance and $startTime$: earliest time for transaction submission*/   Output:  an integer representing the level of partnership   1 /*The DO classify partnership levels based on the number of traded products*/   2 /*${\eta }_i$: the number of products, ${\mathcal{L}}_i$: the level of partnership */   3 Create a map $Map:{\eta }_i\to {\mathcal{L}}_i(i=1,2,\cdots ,m)$   4 $productCount\leftarrow 0$   5 /*Search all product IDs of DO’s participating transactions   6 $all{P}_{id}=\mathit{SearchPidByUid}\left(D{O}_{id}\right)$   7 /*Count the number of products that satisfy the constraint*/   8 for$p_{id}\mathbf{in}all{P}_{id}$do   9   /*Call the method ComputeTxD in the system contract */ 10   $dist=S{C}_{sys}.ComputeTxD(D{O}_{id},D{R}_{id},p_{id},startTime)$ 11   /* Verify that the transaction distance satisfies the constraint */ 12   if $di{s}_{min}\le dist\mathbf{and}dist\le di{s}_{max}$ then 13      $productCount=productCount+1$ 14   end 15 end 16 /*Determining the level of partnership*/ 17 for$i=m\mathbf{in}1$do 18   if $productCount\ge {\eta }_i$ then 19      return $Map\left[{\eta }_i\right]$ 20   end 21 end 22 return 0

4.4. PA-CP-ABE Algorithm Description

Our extended PA-CP-ABE algorithm is based on the construction presented in [13] and mainly consists of five parts: Setup, AttrDef, KeyGen, Encrypt, and Decrypt. The details are as follows.

(1) $\mathrm{Setup}\left(1^{\lambda }\right)\to (\mathrm{PK},\mathrm{MSK})$. The $\mathrm{Setup}$ algorithm outputs the system public and private key pair $(\mathrm{PK},\mathrm{MSK})$ by inputting the security parameter $\lambda$. There is a bilinear map $e:\mathbb{G}\times \mathbb{G}\to {\mathbb{G}}_T$, where $\mathbb{G}$ and ${\mathbb{G}}_T$ are two multiplicative cyclic groups with prime order p; g is a generator of $\mathbb{G}$. This algorithm chooses a cryptographic hash function $H:{\{0,1\}}^{\ast }\to \mathbb{G}$, which maps a binary string describing an attribute to a hash value in the group $\mathbb{G}$. In addition, it chooses random exponents $\mu ,\zeta \in {\mathbb{Z}}_p$, and outputs system key pair (PK,MSK) as

$$\begin{array}{c}\hfill \mathrm{PK}=(g,e{(g,g)}^{\mu },g^{\zeta }),\mathrm{MSK}=g^{\mu }.\end{array}$$

(2) $\mathrm{AttrDef}({\delta }_{{DO}_i},\mathrm{Exp})\to P{A}_{{DO}_i}$. The AttrDef algorithm outputs the personalized attribute $P{A}_{{DO}_i}$ for ${DO}_i$ by inputting the identifier ${\delta }_{{DO}_i}$ of the data owner and the partnership conditional expression Exp; $P{A}_{{DO}_i}$ is abbreviated to $PA$ where there is no confusion.

(3) $\mathrm{KeyGen}(\mathrm{MSK},{\delta }_{{DR}_j},P{A}_{{DO}_i},$S) → SK. The attribute private key generation algorithm inputs the system private key $\mathrm{MSK}$, the identifier ${\delta }_{D{R}_j}$ of the data requester ${DR}_j$, the personalized attribute $P{A}_{{DO}_i}$, the attribute set S of the data requester ${DR}_j$, and outputs the attribute private key SK for the data requester ${DR}_j$. Here, the inputs ${\delta }_{{DR}_j}$ and $P{A}_{{DO}_i}$ are for verifying that the data requester satisfies the data owner’s personalized attribute. This verification process is performed by the attribute authority invoking the smart contract. The algorithm chooses a random $r\in {\mathbb{Z}}_p$ and creates the private key as

$$\begin{array}{c}\hfill \mathrm{SK}=(K=g^{\mu }{g}^{\zeta r},P=g^r,{\{K_x=H{\left(x\right)}^r\}}_{x\in S\cup PA}).\end{array}$$

(4) Encrypt(PK, $m,(M,\rho ))$→ CT. The encryption algorithm takes as input the public parameters PK, a message m to encrypt, and an LSSS access structure $(M,\rho )$.

In the encryption process, $M$ is the access matrix of $l\times n$, $M_i$ denotes the ith row in the matrix, $i\in [1,2,\cdots ,l]$. The function $\rho$ associates rows to attributes. The algorithm selects a random vector $\nu =(s,t_2,\cdots ,t_n)\in {\mathbb{Z}}_p^n$ to generate ciphertext information $(C,C^{\prime })$; s is the secret of the encryption exponent, and $t_2,\cdots ,t_n$ is a series of random values. The algorithm selects random $r_1,r_2,\cdots ,r_l\in {\mathbb{Z}}_p$ and adds additional information ${(C_i,D_i)}_{i\in [1,l]}$ to the ciphertext. Finally, the ciphertext CT is published as

$$\begin{array}{c}\hfill \mathrm{CT}=(C=me{(g,g)}^{\mu s},C^{\prime }=g^s,{(C_i=g^{\zeta {\lambda }_i}H{\left(\rho \left(i\right)\right)}^{-r_i},D_i=g^{r_i})}_{i\in [1,l]}).\end{array}$$

(5) Decrypt(CT,SK)$\to m$. The decryption algorithm inputs a ciphertext CT about the access policy $(M,\rho )$, and a private key SK about the attribute set $S^{\prime }=S\cup PA$ of the data requester. If the attribute set $S^{\prime }$ of the data requester satisfies the access policy $(M,\rho )$, the plaintext m is the output, otherwise, the decryption fails.

Let the set of attribute index be $I=\{i:\rho \left(i\right)\in S^{\prime }\}$ and the target vector be $(1,0,\cdots ,0)$. If the attributes of the data requester fully meet access matrix ${\left(M\right)}_{i\in I}$, it is able to find a set of vectors ${\left\{w_i\right\}}_{i\in I}$ such that ${\displaystyle \sum _{i\in I}}{w}_i{M}_i=(1,0,\cdots 0)$, then we have ${\displaystyle \sum _{i\in I}^{}}{w}_i{\lambda }_i=s$. The decryption algorithm computes

$$\frac{e(C^{\prime },K)}{{\displaystyle \prod _{i\in I}}{\left(e(C_i,P)e(D_i,K_{\rho \left(i\right)})\right)}^{w_i}}=\frac{e{(g,g)}^{\mu s}e{(g,g)}^{s\zeta r}}{{\displaystyle \prod _{i\in I}}e{(g,g)}^{\zeta r{\lambda }_i{w}_i}}=\frac{e{(g,g)}^{\mu s}e{(g,g)}^{s\zeta r}}{e{(g,g)}^{\zeta r{\displaystyle \sum _{i\in I}^{}}{w}_i{\lambda }_i}}=e{(g,g)}^{\mu s}.$$

Finally, we get the $m=\frac{C}{e{(g,g)}^{\mu s}}$.

5. Security Analysis

5.1. Security Analysis of the PA-CP-ABE Algorithm

We formally define the desired security property based on an interactive game consisting of an adversary and a challenger. The adversary interacts with the challenger to attack our PA-CP-ABE algorithm. We then prove that our PA-CP-ABE satisfies the security property based on the paradigms in [13].

Theorem 1.

If decisional q-parallel BDHE assumption holds, then no polynomial-time adversary can choose the challenge access structure $({\mathit{M}}^{\ast },{\rho }^{\ast })$ to break the PA-CP-ABE algorithm.

Proof. 

If there exists a polynomial-time adversary $\mathcal{A}$ choosing a challenge access structure $({\mathit{M}}^{\ast },{\rho }^{\ast })$, wins the game by a non-negligible advantage $\epsilon$, then there exists a simulator $\mathcal{B}$ that solves the decisional q-parallel BDHE assumption by a non-negligible advantage $\epsilon$.

(1) Init. $\mathcal{B}$ takes in a q-parallel BDHE challenge $y,T$; $\mathcal{A}$ gives the algorithm the challenge access structure $({\mathit{M}}^{\ast },{\rho }^{\ast })$, where ${\mathit{M}}^{\ast }$ has $n^{\ast }$ columns, and $n^{\ast }\le q$.

(2) Setup. $\mathcal{B}$ randomly selects a number ${\mu }^{\prime }\in {\mathbb{Z}}_p$, and lets $\mu ={\mu }^{\prime }+{\zeta }^{q+1}$ such that $e{(g,g)}^{\mu }=e{(g,g)}^{{\mu }^{\prime }+{\zeta }^{q+1}}=e{\left(g^{\zeta },g\right)}^{{\zeta }^q}e{(g,g)}^{{\mu }^{\prime }}$. Next, $\mathcal{B}$ chooses a random oracle H and builds a table. When H is called, the result is returned directly if $H\left(x\right)$ already exists in the table, and if $H\left(x\right)$ does not exist in the table, $z_x\in {\mathbb{Z}}_p$ is chosen randomly. Let X be the index set $X=\left\{i:{\rho }^{\ast }\left(i\right)=x\right\}$. If x is an element in the set of system attributes, $H\left(x\right)=g^{z_x}{\prod }_{i\in X}(g^{\frac{\zeta {\mathit{M}}_{i,1}^{\ast }}{b_i}}.g^{\frac{{\zeta }^2{M}_{i,2}^{\ast }}{b_i}}\cdots g^{\frac{{\zeta }^{n^{\ast }}{M}_{i,n^{\ast }}^{\ast }}{b_i}})$.

(3) Query 1. $\mathcal{A}$ queries the private key by submitting a set $S^{\prime }=\{P{A}_{D{O}_i},S_1,S_2,\cdots ,S_n\}$, where $P{A}_{D{O}_i}$ is the personalized attribute of a data owner and $S^{\prime }$ does not satisfy access policy $({\mathit{M}}^{\ast },{\rho }^{\ast })$; $\mathcal{B}$ runs the private key generation algorithm KeyGen to generate the corresponding private key SK = $(K,P,K_x)$ to the adversary. The following is the construction process of the private key. According to the LSSS, $\mathcal{B}$ can find a vector $w=\left(w_1,w_2,\cdots ,w_n\right)\in {\mathbb{Z}}_p^{n^{\ast }}$ such that $w{M}_i^{\ast }=0$, where $w_1=-1$; $\mathcal{B}$ defines implicitly $t=r+w_1{\zeta }^q+w_2{\zeta }^{q-1}+\cdots +w_n^{\ast }{\zeta }^{q-n^{\ast }+1},r\in {\mathbb{Z}}_p$, then it computes $P=g^r{\prod }_{i=1,\cdots ,n^{\ast }}{\left(g^{{\zeta }^{q+1-i}}\right)}^{w_i}=g^t$. To eliminate item $g^{{\zeta }^{q+1}}$, $\mathcal{B}$ uses $\mu ={\mu }^{\prime }+{\zeta }^{q+1}$ to define K as

$$\begin{array}{c}\hfill K=g^{\mu }{g}^{\zeta t}=g^{{\mu }^{\prime }+{\zeta }^{q+1}}{g}^{\zeta t}=g^{{\mu }^{\prime }}{g}^{\zeta r}{\displaystyle \prod _{i=2,\cdots ,n^{\ast }}}{\left(g^{{\zeta }^{q+2-i}}\right)}^{w_i}.\end{array}$$

The attribute set $S^{\prime }$ submitted by the data requester $DR$ consists of two parts: the system’s predefined attribute set $S=\{S_1,S_2,\cdots ,S_n\}$ and the data owner’s personalized attribute set $PA=\{P{A}_1,P{A}_2,\cdots ,P{A}_n\}$, i.e., $S^{\prime }=S\cup PA$; $\mathcal{B}$ can compute K as

$$\begin{array}{l}{K}_x=H{\left(x\right)}^t=P^{z_x}{\displaystyle \prod _{i\in X}}{\displaystyle \prod _{j=1,\cdots ,n^{\ast }}}{\left(g^{\frac{{\zeta }^j}{b_i}r}{\displaystyle \prod _{\begin{array}{c}m=1,\cdots ,n^{\ast }\\ m\ne j\end{array}}}{\left(g^{{\zeta }^{q+1+j-m}}\right)}^{w_m}\right)}^{M_{ij}^{\ast }},x\in S\\ K_x=H{\left(x\right)}^t=g^{z_{x}t}=P^{z_x},x\in PA.\end{array}$$

(4) Challenge. $\mathcal{A}$ sends two messages $m_0,m_1$ of equal length to $\mathcal{B}$; $\mathcal{B}$ randomly picks $c\in \{0,1\}$, then it uses the access structure $(\mathit{M},\rho )$ to encrypt $m_c$ such that $C=m_c\mathrm{T}e{(g,g)}^{\mu s}$ and $C^{\prime }=g^s$. Next, $\mathcal{B}$ chooses randomly $y_2^{\prime },y_3^{\prime },\cdots ,y_{n^{\ast }}^{\prime }$ and shares the secret key by $v=(s,s\zeta +y_2^{\ast },s{\zeta }^2+y_3^{\ast },\cdots ,s{\zeta }^{n-1}+y_{n^{\ast }}^{\ast })\in Z_p^{n^{\ast }}$. Finally, $\mathcal{B}$ chooses randomly $r_1^{\prime },\cdots ,r_{l^{\ast }}^{\prime }\in Z_p$ and defines $R_i$ as the set of ${\rho }^{\ast }\left(i\right)={\rho }^{\ast }\left(m\right)$ ($m\ne i$). The ciphertext is created as

$$\begin{array}{l}{C}_i=H{\left({\rho }^{\ast }\left(i\right)\right)}^{r_i^{\prime }}\left({\displaystyle \prod _{j=2,\cdots ,n^{\ast }}}{\left(g^{\zeta }\right)}^{M_{i,j}^{\ast }{y}_j^{\prime }}\right){\left(g^{b_{i}s}\right)}^{-z_{p^{\ast }\left(i\right)}}.\left({\displaystyle \prod _{m\in R_i}}{\displaystyle \prod _{j=1,\cdots ,n^{\ast }}}{\left(g^{{\zeta }^{j}s\frac{b_i}{b_m}}\right)}^{M_{m,j}^{\ast }}\right),\\ D_i=g^{-r_i^{\prime }}{g}^{-s{b}_i}.\end{array}$$

(5) Query 2. Same as Query 1.

(6) Guess. $\mathcal{A}$ outputs a guess $c^{\prime }$ of c, where $c^{\prime }\in \{0,1\}$. Next, $\mathcal{B}$ outputs $\theta =0$ if $c^{\prime }=c$ which shows that $T=e{(g,g)}^{{\zeta }^{q+1}s}$; otherwise, $\mathcal{B}$ outputs $\theta =1$ to show that T is a random group element in ${\mathbb{G}}_T$. When $c^{\prime }=c$, the advantage of $\mathcal{A}$ is $\mathrm{Pr}[c=c^{\prime }|\theta =0]=\frac{1}{2}+\epsilon$. When $c^{\prime }\ne c$, the advantage of $\mathcal{A}$ is $\mathrm{Pr}[c=c^{\prime }|\theta =1]=\frac{1}{2}$. The advantage gained by adversary $\mathcal{A}$ in attacking q-parallel BDHE assumption is

$$\begin{array}{c}\hfill {\mathrm{Adv}}_{\mathcal{A}}=\left|\frac{1}{2}\mathrm{Pr}[c=c^{\prime }|\theta =0]+\frac{1}{2}\mathrm{Pr}[c=c^{\prime }|\theta =1]-\frac{1}{2}\right|=\frac{1}{2}\epsilon \end{array}.$$

Therefore, the advantage of any polynomial-time adversary in winning the game is negligible. □

5.2. Security Analysis of Our SDSM Scheme

Among the security goals of our scheme, the focus is on data privacy and resistance to collusion attacks. Recently, Jia et al. [30] proposed a consensus-based distributed auction scheme for enhancing privacy protection and resisting collusion in data sharing. Unlike this, our scheme is mainly based on cryptographic policies to reach these security goals.

Data Privacy: In our scheme, a hybrid key encapsulation mechanism is used for encryption, i.e., we encrypt the original data using the symmetric $K_{sym}$ and then encrypt the $K_{sym}$ again using the attribute encryption. This is similar to the method in [33]. Although the cloud service provider is a semi-trusted entity, it must obtain the session key to decrypt the shared data stored by the data owner. However, the session key has been encrypted by our PA-CP-ABE algorithm and stored on the blockchain. Due to the open nature of the blockchain, all nodes can synchronize the entire full block. After extracting the transaction data on the block, only the private key that fully satisfies the access policy can decrypt these transaction data. Therefore, our system can protect the data privacy of supply chain participants.

Resisting Collusion Attack: In the CP-ABE scheme, if the attributes of two or more data requesters do not satisfy the access policy, the decryption of data is achieved by merging their attribute keys, and we say that the scheme is not resistant to collusion attack. We introduce personalized attributes of the data owner for the CP-ABE scheme, which may serve as an entry point for attackers. However, in our PA-CP-ABE algorithm, the attribute authority aggregates these attributes to generate the attribute private keys after verifying whether the data requester satisfies the personalized attributes. That is, these attribute private keys use the same batch of random factors. When different data requesters request their own attribute private keys, the attribute authority uses different random factors, so they will not be able to complete the decryption of the ciphertext by combining their respective private keys.

6. Performance Evaluation

Our secure data sharing scheme combines attribute cryptography and blockchain technology, so we evaluated the efficiency and reliability of our scheme from two perspectives, the first involving the core algorithms in the attribute cryptography scheme, and the second involving data publishing and smart contract execution on the blockchain.

6.1. Comparison of Encryption Schemes

For the CP-ABE scheme, we used the JPBC library for the implementation and selected several related works [14,31,32] to compare with our scheme. The ciphertext-based attribute encryption scheme (CP-ABE) proposed by Bethencourt et al. [14] served as the baseline for our comparison. Our proposed attribute encryption scheme (PA-CP-ABE) was compared with the other two most relevant schemes, namely, the File Hierarchical Attribute Encryption scheme (FH-CP-ABE) proposed by Wang et al. [31] and the Permission-based Multilevel Organisation Data Encryption scheme (P-MOD) proposed by Zaghloul et al. [32]. The FH-CP-ABE scheme integrates layered access structures into a single access structure, and then encrypts the layered files with the integrated access structure. This scheme saves the cost of storing the ciphertext and the time cost of encryption, but the access structure will become relatively complex and increase the generation time of the decryption key. The P-MOD scheme requires the existence of a clear hierarchy in the organization of the data requester. This allows the data owner to design access policies based on different hierarchies and to divide the file into different sections, each assigned a different hierarchy. Each file part is encrypted with a symmetric key and is able to derive the key of the lower-level part from the key of the higher-level part.

We completed two tests on a personal computer, a laptop with a 6-core, 12-thread CPU and 32G RAM. The two tests were: (1) the attribute encryption and decryption of the transaction data; and (2) the generation of the data requester’s private key.

As shown in Figure 4a,b, the time overhead of our scheme is significantly smaller than the other three schemes. This is mainly because the other three schemes use policy trees as the access structure, whereas our scheme adopts LSSS. On the other hand, the comparison between Figure 4a,d also shows that the overhead of the CP-ABE scheme is particularly high as the attribute number increases.

The experiments are conducted from the perspective of the data requester appearing at the highest level of the hierarchy. Taking this into account, the decryption time cost is defined as the time for the data requester to successfully decrypt the ciphertext for all levels. Figure 4b,e show the time to perform the decryption function for each scheme. Because our scheme and P-MOD follow a similar multilevel key generation approach, they are relatively convergent in terms of the time overhead of the decryption process. When measuring the decryption time cost, the time overhead of our scheme and P-MOD decreases instead as the value of k increases. This is because, with a fixed size of the shared data files, the larger the value of k, the smaller the file share of each level. From Figure 4c,f, we can see that our scheme lags behind P-MOD in terms of the efficiency of key generation. This is due to the addition of personalized attributes to our scheme, and the values of the attributes require calls to smart contracts to complete the computation, which increases the time overhead.

6.2. On-Chain Overhead of Our System

To achieve secure data sharing, both our scheme and the work in [33] utilize a blockchain to store the encrypted pointers to shared data. The difference is that we use smart contracts to verify the personalized attributes of data requesters, whereas the scheme in [33] uses smart contracts to check the satisfaction of access policies. In order to verify the feasibility of our proposed secure data sharing scheme (SDSM), we built a consortium blockchain experimental platform (based on Hyperledger Fabric 2.2) and implemented a simulation system in this environment. The environment is configured as follows:

• The experimental network is built on a private cloud platform formed by four computing servers and one storage array.
• The experimental network is a local area network with a data transfer speed of 1000 Mbps.
• Each computing server is configured with two E5-2650v4 processors (12 cores and 24 threads each) and 128G of RAM, and the storage array is configured with 54 TB of enterprise-class SATA hard disks.
• Through virtualization technology, forty virtual servers are configured with two cores and 8 G of RAM assigned to each virtual server.
• Thirty virtual servers act as Hyperledger Fabric nodes, five virtual servers act as cloud storage servers, and the remaining five virtual servers act as attribute authority servers.

We created 100 participants with 10,000 products for a hypothetical supply chain and classified the suppliers into six classes. We randomly generated 50,000 transaction records according to a normal distribution, with 1–3 point transactions associated with each product transaction record. Both the data transactions and the point transactions are stored on the blockchain. The point transactions store the encrypted pointers to the data participants want to share, whereas the actual data to be shared is stored on the cloud platform. Each point transaction corresponds to a data sharing operation initiated by a participant and contains data ranging from 1 MB to 10 MB in total size. These data are divided into multiple files based on sensitivity, and each file can only be accessed by the partners who have reached the corresponding level. In our secure data sharing scheme, there are two functions that rely on the blockchain to be accomplished. One is that the encrypted pointer of the data shared by supply chain participants are published to the blockchain after being encrypted by attributes. The other is that the metrics of partnerships between participants require the aid of smart contracts to complete. Therefore, we completed two blockchain-related tests: (1) the throughput rate of data storage transactions uploaded to the blockchain; and (2) the average execution time of smart contracts used to validate partnerships. In our experiments, the AA acts as a blockchain node, whereas DOs and DRs act as clients.

The test results show that the processing efficiency of data publishing is stable above 9000 TPS, as shown in Figure 5a. We can also observe from the figure that the TPS decreases slightly as the submitted data increase and the number of blocks grows. This is because each of our data upload transactions contains two read and two write operations. The larger the number of blocks, the longer the read operation takes. We focus on the execution time of the validation contract because it determines the utility of our online attribute validation scheme. The validation contract mainly involves statistical queries on the size of historical transactions between participants, which is obviously affected by the growth of data volume. As shown in Figure 5b, the time consumed per query is essentially within 1 ms when the block count is small. When the number of blocks grows to more than 2000, the query time grows to more than 1 ms. Eventually, the query time stabilizes within 2 ms. From the above two tests, we can conclude that the time overhead of on-chain operations is within an acceptable time range, which indicates the feasibility of our scheme.

7. Conclusions

We proposed a secure data sharing scheme (SDSM) for IoT based supply chains by combining blockchain and ciphertext-based attribute encryption. The scheme supports the implementation of fine-grained access control for different levels of partnerships. There are two objectives achieved through blockchain technology. The first objective is to establish a trusted data sharing platform, where data requesters in the supply chain can verify the authenticity of the shared data. The second objective is to design a method to automatically calculate the partnership levels among participants through smart contracts based on the historical transaction facts on the blockchain. This method allows data owners to specify level thresholds to avoid arbitrariness in determining partnership levels while also reducing computational effort. We introduced personalized attributes of participants in the ciphertext-based attribute encryption algorithm and described the partnership levels by these attributes to enhance the expression of the access policy. By correlating the partnership level with the sensitivity of the data, we provide more fine-grained access control for shared data. Compared to other hierarchical data sharing schemes noted in the paper, our scheme provides an automated calculation of the data requester hierarchy. The simulations and analyses demonstrate the feasibility of our scheme. Our scheme currently only considers the case of a single supply chain, which may not be well suited for data sharing and collaboration scenarios between supply chains. In the future, we will investigate a secure data sharing scheme across multiple supply chains.