Abstract

Microgrid is a power system that includes various energy sources (e.g., solar panels and wind turbines), where a number of device status and sensing data are collected and transmitted by smart sensors. Based on sensing-as-a-service in microgrid, sensor owners and sensor data consumers can effectively perform data sharing operations. However, the state-of-the-art sensor data sharing works in microgrid have the following two limitations: (i) cannot support fine-grained authorization for sensor owners and sensor data consumers and (ii) fail to simultaneously consider confidentiality and authenticity for sensor data sharing. To address the problems, in this article, we propose a lightweight privacy-preserving sensing data sharing system with fine-grained authorization in microgrid. Technically, we employed attribute-based signature methodology to design a fined-grained authorization mechanism for sensor data users. Moreover, a lightweight hyper elliptic curve-based signcryption scheme is employed to provide confidentiality and authenticity for sensor data sharing. To clarify the feasibility of our proposed system, we implement the system and evaluate the performance. The experimental results show that the system achieves small communication and time overhead, as well as highly acceptable gas consumption of smart contract.

1. Introduction

With the access of multiple energy sources and numerous power loads, the traditional power system is rapidly evolving into a microgrid [1]. Specifically, a microgrid is a self-sufficient power system that includes distributed power sources, energy storage devices, transmission grids, and user loads. Due to the rapid development and wide employment of 5G and Internet of Things (IoT) [2], the microgrid system can perform measurement operations (e.g., data collection, data transmission, and data analysis) based on smart IoT devices. Hence, the information of microgrid operation status, equipment status, and energy data are effectively sensed and monitored by these smart sensors, which provides a guarantee of safe operation for microgrid. According to an IHS analysis, the smart grid or microgrid-related sensor market has grown nearly tenfold between 2014 and 2021, reaching 350 million dollars, which is expected that there will be 41.6 billion IoT sensing devices by 2025.

There are amounts of sensors and connected devices that is deployed in microgrid, which is followed by the large-scale data perception and processing tasks. This motivates the employment of Sensor-as-a-Service (SaaS) [3] into the microgrid (as illustrated in Figure 1), which is driven and influenced by cloud computing service. In SaaS, sensor owner can collect, packet, and process sensing data, thus data consumers can reuse and acquire sensing data with relatively low cost. As a result, sensor owners and data consumers can securely and effectively perform data sharing and trading [4]. Since the fairness of data sharing and transactions in traditional SaaS model only relies on the service provider. Once the trust of service providers is lost, the security and fairness of data sharing may become a serious challenge.

In data sharing service, the primary security goal and fairness is to ensure that the real identities of users and transmitted data are not leaked, and third-party involvement should be avoided as far as possible in the transaction process to maximize the interests of both parties. To achieve data privacy and fairness, blockchain [5] was introduced into data sharing services. Blockchain is a decentralized platform that combines peer-to-peer networks, cryptographic protocols, distributed data storage, and consensus mechanisms, where a number of transactions that used for recording data interaction is created and packaged into a block and added to the blockchain by miners. After that, every peer node can verify the validity of data transactions through cryptographic algorithms and consensus protocols. Due to these positive characteristics, blockchain technology has been extensively researched and deployed in practical data sharing services [4, 69].

The recent proposed blockchain-based data sharing systems [6, 7, 9] considered different properties of privacy-preserving in data sharing services, such as fairness, anonymity, and traceability. To enable users more willing to participate in data sharing, Samuel et al. [8] combined access control module with differential privacy and thus gave a blockchain-based fair data sharing for deregulated smart grids. By combining the advantages of IoT and SaaS in smart city, Lin et al. [4] presented an effective blockchain-based data sharing system based on symmetrical encryption and signature, Paillier encryption, and -protocol. Nevertheless, these blockchain-based data sharing systems cannot be directly used in microgrid driven by sensing-as-a-service. This is because of the following reasons:(i)The sensor devices in microgrid are usually equipped with more constrained computation and storage resources(ii)The number of sensor owners and data consumers are large that require fine-grained access control strategies(iii)The shared sensor data is usually provided with either data confidentiality guarantee or data authenticity guarantee

1.1. Our Results
1.1.1. Motivation

To address the problems, we proposed an effective blockchain-based sensor data sharing system in microgrid, which considers practical efficiency and security requirements. Generally, the service provider can perform fine-grained authorization over data user registration and achieve lightweight enhanced privacy-preserving of data confidentiality and data authenticity for the shared sensor data.

In particular, the contributions of this work can be summarized as follows:(1)Fine-grained authorization. To enable the system to perform fine-grained authorization to sensor owner and data consumers, we design a fine-grained authorization mechanism based on attribute-based signature for user registration. In particular, a registered user is granted with a corresponding number of pseudonyms. As a result, not only the real identity of the user is preserved, but also the fine-grained access control of user registration is realized.(2)Enhanced privacy-preserving data sharing. To provide enhanced privacy guarantee for the blockchain-based data sharing platform, we use a lightweight hyper elliptic curve-based signcryption scheme to achieve both confidentiality and authenticity for the shared sensor data. In particular, we employed a key encapsulation mechanism into our sensor data sharing system, where the sensor data is encrypted by AES and the key of AES is signcrypted by the lightweight hyper elliptic curve-based signcryption scheme.(3)Reputation-based sensor owner selection. To prevent much manual intervention for a sensor owner selection, we employed a blockchain platform with constructing an effective and efficient sensor owner selection model based on reputation calculation. In particular, we designed smart contracts and formulate a reputation calculation function for each sensor owner, where the function considers the following factors, such as transaction frequency, positive and negative reviews, and the real-time nature of reviews.

In addition, we write the codes and deploy the corresponding smart contracts in Remix Rem. Particularly, we designed 8 functions in smart contracts and evaluate their gas cost, where the cost is all below . Moreover, we evaluate the communication cost and computational overhead of AES, attribute-based signature, and signcryption that are used in our proposed system, where the cost is highly acceptable due to simple AES and lightweight hyper elliptic curve-based signcryption scheme.

1.1.2. Organization

Section 2 reviews some background knowledge and Section 3 formalizes the system model and security requirements. In Sections 4 and 5, we presented the construction and security analysis of the proposed sensor data sharing system in microgrid. Section 7 surveys recent related works and Section 8 finally concludes this work.

2. Preliminaries

2.1. Blockchain and Smart Contract

Blockchain is a decentralized distributed ledger that can record, store, and update data in a distributed manner. Transactions, in a blockchain, are the most basic activities that miners create, record, and approve in a block. Miners who with accounting rights send the blocks they create to each peer node in the system via a consensus algorithm. When received by other nodes, blocks are verified for hash, signature, and transaction validity, and after the consensus is formed, they are added locally. Furthermore, when the preparatory conditions are met, smart contracts execute, which are stored on the blockchain. They typically act as protocols enforced by specific rules that are predefined by computer code and replicated and enforced by all network nodes.

2.2. Attribute-Based Signature

Li et al. [10] initiates the notion of attribute-based signature (ABS), in which a sensor owner can sign messages with any policy that composed up of a number of attributes. Correspondingly, only the specified policy is revealed to the public while the user’s identity is kept in privacy.(1): This algorithm takes a security parameter as input and generates a public parameter and a master key .(2): This algorithm takes and a data user’s attributes as inputs and generates a private key for the user.(3): This algorithm takes , a message , a data user’s , a policy that accepts , and finally signs the message to output a signature .(4): This algorithm takes and attributes as inputs, and outputs 1 if is a valid signature.

2.3. A Signcryption Scheme Based on Hyper Elliptic Curve

The work in [11] gave a highly efficient signcryption scheme based on hyper elliptic curve, where the signcryption algorithm and unsigncryption algorithm are described as follows:(i)Signcryption (a)Randomly selects an integer (b)(c)(d)(e)Compute (f)Compute (g)Compute (1) Thus, the signcrypted transmitted text is .(ii)Unsigncryption (a) Compute (b) (c) (d) Compute (e) Compute (f) Check , if true accept the message, else reject.

3. Problem Formulation

In this section, we formalized the system model and security requirements for our proposed sensor data sharing system in microgrid.

3.1. System Model

There are three main entities that is considered in our proposed data sharing system: sensor owners, data consumers, and service providers, as shown in Figure 2. In particular, the formal descriptions of these entities are as follows:(1)Sensor owners: Sensors usually refer to devices that are connected to various energy equipments for measuring, sensing, and presenting data information (e.g., temperature, humidity, and electricity). In particular, the sensors can satisfy the requirements of information transmission, processing, storage, display, recording, and its characteristics, such as miniaturization, intelligence, networking, and other characteristics. Generally, the sensor owners are independent parties who have these sensors in possession and a sensor owner may own one or more sensors. If the sensor owner is willing to share the data in the sensor, paid, or free, then they can publish the sales information in the system.(2)Data consumers: Data consumers (e.g., energy companies, scientific research teams, and schools) may purchase the sensing data by Saas model. In the system, data consumers can send requests for matching candidate sensor data that is contributed by different sensor owners. If data consumers intend to purchase shared sensor data, they may pay a deposit to the sensor owner in advance, and then pay the corresponding balance after obtaining all sensor data. Moreover, all transaction processes are automatically completed via the smart contracts in the system.(3)Service provider: The honest and curious service provider runs registration service for sensor owners and data consumers, where only the registered parties can conduct data transactions in the system. Note that the registration service is completed based on the deployed smart contracts in the system. In addition, the service provider stores the data to be shared on its behalf, and after the transaction takes place, transmits the data to the data consumer.

3.2. High-Level Overview

As shown in Figure 3, we presented a high-level overview of the system as follows:Step 0: Sensor owners or data consumers who want to join in the system should complete the registration procedure with the service provider at first.Step 1: A sensor owner uses a wireless connection with the service provider for data transmission, where it needs to transmit the sales information and the AES-encrypted sensor data to the service provider.Step 2: After the service provider reviewed the sales information and received the encrypted data, it publishes the sales information on the blockchain platform.Step 3: A data consumer selects a target seller based on its own interests and the sensor owner’s reputation. After that, it needs to upload its request information (e.g., public key and pseudonym) to the smart contract and pay the deposit.Step 4: If a sensor owner agrees to sell sensing data to a data consumer, it first accepts the data consumer’s request and later encrypts the data key by employing a signcryption algorithm, and finally uploads it to the smart contract.Step 5: The data consumer downloads the corresponding file from the platform, decrypts it to obtain the data key, where the balance is automatically deducted from the data consumer’s account.Step 6: The service provider transmits the encrypted data to the data consumer, and the data consumer uses the key to decrypt the encrypted data. If the data consumer finds that the key is invalid, it may submit an appeal to the service provider.

3.3. Design Goals and Security Requirements

The following are the design goals and security requirements that is considered in our proposed system.(1)Privacy-preserving. Sensor owners and data consumers should have a certain number of pseudonyms in the system that they use to use sensor services, and their real identities should be hidden.(2)Unlinkability and revocability. All pseudonyms registered on the service platform by sensor owners and consumers using their real identities cannot be connected. But when users seriously violate the rules, the system should have the right to reveal the real identity behind the pseudonym and revoke their right to use the service.(3)Data integrity and reliability. When the sensor owner encrypts and sends the data to the service provider, the service provider does not have the decryption key, so it only temporarily stores the data and cannot tamper or delete the data without permission. Therefore, the integrity and reliability of the data are guaranteed.(4)Fairness. On one hand, data consumers cannot obtain sensor data without paying a corresponding deposit. On the other hand, sensor owners should be caught and penalized if they provide invalid sensor data to sensor data consumers.

4. System Design

For our proposed sensor data sharing system in microgrid, we gave a formal description of the system running flow.

4.1. Running Flow

The running flow of the system consists of initialization, registration, publication, request, response, retrieval, guarantee, and evaluation phase. In addition, the functions in the smart contract includes uploadRegInfo, publishSales, uploadRequest, getRequest, uploadRes, getRes, submitAppeal, and calReputation. In particular, these functions are mainly focused on uploading registration information, publishing sales information, uploading purchase requests, receiving purchase requests, uploading responses information, receiving responses, submitting appeals, and calculating reputation in the above process. In particular, the formal descriptions of the proposed system are as follows:

4.1.1. Initialization

The users (sensor owners and data consumers) are authenticated by the ABS algorithm before they participate in the system. Specifically, the system calls ABS.Setup() to set public parameter and master key , and sends the access structure to the user, while the user needs to submit its attribute set that satisfies . Then, ABS.KeyGen() inputs , and to generate the user’s private key . Finally, the algorithm ABS.Sign() outputs a signature that satisfies the condition.

4.1.2. Registration

The service provider in the system provides registration service. Both the sensor owner and the sensor data consumer must complete the registration in the service provider. Only the registered entities can enjoy the services in the system. First, the registration entity submits the corresponding information (, , and ) to the service provider( is the real identity of the registered user). Then, the service provider calls the ABS.verify() to verify the authenticity of the registration information. Only those who have passed the verification can complete the registration, otherwise the registration will fail. Then, the system automatically generates a certain number of pseudonyms based on the attribute set of the registered user to protect their privacy. Finally, and will be submitted to the blockchain through uploadRegInfo. The registration and uploadReginfo algorithm is described in Algorithm 1. Note that the service provider locally stores the real identity of the registered user for subsequent tracking of requirements.

Require: a user’s attribute set and real identity .
Ensure: the pseudonym of users .
(1)if ABS.verify(b = 1) then
(2) register successful;
(3) uploadReginfo ;
(4)else
(5) return false;
(6)end if
4.1.3. Publication

When a sensor owner wants to publish data sales information, he first needs to call the to encrypt the data into ciphertext , and then transmit it to the service provider through the sensor (each sensor has a corresponding ID ). The service provider receives the ciphertext and publishes the sales information through publishSales in the smart contract (as shown in Algorithm 2). The published information includes the seller’s pseudonym , the information info of the sensor data , and the expected price .

Require: service provider has received the sensor data.
Ensure: publish sales information successfully.
(1)if (receive status) = ; then
(2) Sales.sid = ;
(3) Sales.pidu = ;
(4) Sales.info = ;
(5) Sales.price = ;
(6)else
(7) return false;
(8)end if
4.1.4. Request

Sensor consumers can choose the data they are interested in or want to buy based on the published sales information. If the sensor consumer selects a certain sensor owner, that is, the seller, upload the consumer’s own public key , its own pseudonym , the seller’s pseudonym , and the index of the data in the hyper elliptic curve-based signcryption algorithm to the smart contract through uploadRequest in Algorithm 3. As for how consumers can choose sellers efficiently, they can make decisions based on the reputation value of the sellers, which will be described in detail in Section 4.2.

Require: Consumer’s public key, pseudonyms of both parties, and data index
Ensure: upload request successfully.
(1)if (selected status) = ; then
(2) Req.cpk = ;
(3) Req.consumer = ;
(4) Req.owner = ;
(5) Req.data = ;
(6)end if
4.1.5. Response

The sensor owner can obtain the consumer’s request information through getRequest in the smart contract. If the owner agrees with the quotation and other matters in the request information, it encrypts its own symmetric key through signcryption (, , , , and ) and obtains the transmission text . Here, refers to the ciphertext of the sensor owner in the signcryption algorithm, while and are the generated signature; refers to the private key of the sensor owner, and are the public keys of the sensor owner and the data consumer. Then, it sends a tip information that agrees to the request to the service provider and calls uploadRes as in Algorithm 4 to upload the transmitted text to the smart contract.

Require: send a to the service provider
Ensure: upload response successfully.
(1)if ST(status of ) = ; then//the tip has been sent
(2) Res.text[] = ;
(3) Res.owner = ;
(4) Res.consumer = ;
(5)else
(6) return “please send a agreeing to the request”;
(7)end if
4.1.6. Retrieval

The data consumer gets the corresponding file from getRes in the smart contract, and decrypts it through unsigncryption to obtain the data key . Note that the check() algorithm in unsigncryption can verify whether the signcryption calculation is performed using the public key provided by the consumer, which provides verifiability. After that, the consumer requests the encrypted data from the service provider. Of course, for the security of the transaction, the service provider will verify that the sensor owner has agreed to the request before transmitting the data to the consumer. Finally, when the consumer receives the data transmitted by the provider, he decrypts the original sensor data using the AES.dec . Note that when sensor data is obtained, the system will automatically debit the consumer’s account and credit the remaining fee to the sensor owner’s account.

4.1.7. Guarantee

If the consumer finds that the key is invalid, i.e., the sensor owner has provided a fake data key, he can submit an appeal to the service provider via submitAppeal. The service provider reverifies the situation and orders the sensor owner to provide the consumer with a valid key. If the sensor owner continues to provide invalid keys, the service provider will reveal the real identity behind the pseudonym and block all pseudonyms , and also the data consumer’s funds will be returned.

4.1.8. Evaluation

After a transaction cycle is completed, the data consumer can evaluate the transaction, that is, score and evaluate the sensor owner. The range of evaluation points is set from 1 to 10 points, with 6 points or more being positive evaluations and the following being negative evaluations. The evaluation within 1 month is the recent evaluation, otherwise it is the past evaluation, and the time window is 6 months. The calReputation in the smart contract automatically calculates the reputation of the sensor owner based on the above factors.

4.2. Reputation Calculation Model

In the proposed data sharing system, the reputation value of a sensor owner (seller) can be computed in real time by using the reputation calculation model, where the seller with a high reputation means that their data quality and transaction reputation are relatively good. Therefore, data consumers (buyers) can selectively choose sellers with high reputation for data trading. The reputation of the sensor owner is mainly affected by two key factors, transaction frequency, and after-sales evaluation. We combine these two factors to build a reputation calculation model to help consumers choose the right sellers efficiently.(i)Transaction Frequency: The transaction frequency refers to the ratio of the number of transactions between sensor owner and data consumer to the average number of transactions between sensor owner and other data consumers within the time window , namely,where and ( is the total number of data consumers transacting with sensor owner within a time window). In conclusion, higher transaction frequency indirectly indicates a higher reputation of the sensor owner.(ii)Evaluation Timeliness: Data consumers can rate sellers within one month after the transaction. In order to calculate reputation more accurately, the system assumes that recent reviews have a greater impact on the seller’s reputation, while past reviews have less impact. Also, negative reviews have a greater impact on sellers than positive reviews. Therefore, we set the weight of recent evaluations to be , the weight of past evaluations to be ( +  = 1, ), and the recent and past time periods to be one month. Positive reviews are weighted and negative reviews are weighted ( +  = 1 and ). Taking into account two sets of factors, the update transaction frequency formula is as follows:

Among them, when the current time t satisfies (month), the number of recent positive evaluations is , and the number of recent negative evaluations is . For , the number of positive and negative past events are and , respectively. Therefore, the reputation calculation function of the data seller is as follows:

In summary, the calReputation in the smart contract will automatically calculate and present the reputation of the sensor owner in real time according to the function. Data consumers can choose data sellers with high reputation for transactions. Of course, the price of data from sellers with high reputation will be higher.

5. Security Analysis

In this section, we present security analysis of our proposed system.

5.1. Privacy Preserving

The system adopts the ABS signature algorithm in the entity registration stage, and ABS has anonymity. Second, after the user is registered with the service provider, a certain number of pseudonyms s are returned for them to use when transacting. These hide the user’s real identity and protect the user’s privacy well.

5.2. Unlinkability and Revocability

The pseudonyms given by the service provider to the registered entity are only related to the real identity behind it, and there is no link between the pseudonyms. Since the service provider stores the real identity of the user locally, when the user acts dishonestly, the service provider will revoke the right to use the service under a pseudonym.

5.3. Data Integrity and Reliability

The sensor owner encrypts the data in the sensor with the AES algorithm and uploads it to the service provider, and the service provider stores it on their behalf. In the process of data transmission and storage, if there is no corresponding data key , no one can modify and read the data.

5.4. Fairness

There is no third-party intervention in our system during the data transaction process. The service provider only provides the functions of registration, data storage and transmission, and does not enter into the process of data transaction. Additionally, data consumers can submit appeals when sensor owners provide invalid keys. These protect the rights and interests of consumers and ensure the fairness of the system.

6. Experimental Study

In this section, we evaluate the performance of the system, including testing out the gas cost of smart contracts and calculating the computational and communication cost of the cryptographic algorithms used. In particular, to facilitate compiling and testing smart contracts, we implement preops on Remix, a browser-based integrated development environment (IDE) for Ethereum. Specifically, the specific configuration in Remix includes the following: programming language (Solidity), compiler version (>=0.4.22 <0.7.0), and EVM version (default setting). In addition, we also evaluated the communication overhead and the computational cost of specific algorithms at each stage in the system running process.

6.1. Performance of Smart Contracts

The smart contract in the system consists of eight main functions, namely uploadRegInfo, publishSales, uploadRequest, getRequest, uploadRes, getRes, submitAppeal, and calReputation. The total gas cost of deploying smart contracts in the system is , and the gas cost of each part of the function is 0.133, 1.114, 1.686, 0.602, 1.631, 0.103, 0.049, and 0.422 , as shown in Figure 4. Among them, the reputation calculation for the sensor owner consumes a lot of gas, but it achieves our expected effect.

6.2. Communication and Computational Cost

We evaluated the communication and time cost of our system based on the benchmark given by [11], where the hardware is configured as a computer running jdk1.6, with 2 Intel CPU cores, a processing speed of 2.00 GHz, and a main memory capacity of 4 GB. As measured in [11], Table 1 shows time cost for elliptic curve point multiplication and hyperelliptic curve divisor-scalar multiplication, where a single scalar multiplication operation is respective 4.24 ms and 2.2 ms, and we use [12]’s ABS scheme to instantiate our system. In particular, we list some basic symbols in system cryptographic algorithms in Table 2 along with their cost. Therefore, we used these notations to calculate theoretical communication cost for different stages of the system’s operational flow. As shown in Table 3, we only consider dominant operations for calculation, and the communication cost corresponding to initialization, publishing, request, response, and retrieval are 3040 bytes, 40 bytes, 65 bytes, 26 bytes, 66 bytes, and 72 bytes, respectively. In addition, the computational cost of the substeps of the ABS where the number of attributes is 50 and HECCS algorithms in the system are given in Table 4, which are 216.24 ms, 216.24 ms, 220.48 ms, 6.6 ms, and 4.4 ms, respectively.

6.3. Reputation Calculation Analysis

Since the reputation of the sensor owner is affected by the real-time evaluation and the positive and negative effects, as shown in Figure 5, we test the changes of the reputation value in the two time periods of 01 month and 16 months, respectively. Specifically, we preset , , , and in the program, and take half a year as a time window. It can be clearly seen from Figure 5 that the greater the proportion of negative reviews within a month, the faster the decline in reputation value. On the other hand, the number of negative reviews between one month and six months has a lower impact on reputation value. This fully reflects the influence of the number of negative reviews and recent reviews on reputation value.

Access control techniques are widely applied to share data from IoT sensors. Traditional access control techniques include discretionary access control (DAC) [13], role-based access control (RBAC) [14, 15], and capability-based access control (CapBAC) [16]. However, for these traditional models, a centralized authority is usually necessary to configure access control policies, resulting in centralized decision-making. Moreover, access control policies or records stored by a central third-party may be maliciously tampered with, leading to unreliable auditing. Facing this challenge, many attribute-based access controls [17] and attribute-based proxy re-encryption schemes [18, 19] have been proposed, but the issue of unreliable audits still exists in almost all of them. To settle the above issues, researchers combine blockchain technology with access control, which has the benefits of verifiability and decentralization.

Blockchain-based data sharing schemes have been presented in previous researches. Regarding data sharing between individuals and others, Chowdhury et al. [20] proposed a data sharing architecture of personal data with a notarization service offered by blockchain, and applied a blockchain-based mechanism to protect the privacy and integrity of transaction data. For data collected by IoT sensors, Manzoor et al. [21] combined the blockchain technology with the proxy re-encryption scheme to address the third-party trust issues of traditional IoT data sharing and improve scalability while guaranteeing data security. Since there are significant security issues in sharing data among users in multiple organizations, amounts of research has been conducted recently. Chen et al. [6] presented a blockchain-based privacy protection scheme based on k-anonymity and searchable, which achieves security and privacy protection of data in data sharing systems. However, the scheme requires further optimization and improvement for multiple groups data. Based on the Ethereum blockchain technology, Song et al. [22] accomplished the decentralization of the big data sharing system. However, these schemes mainly address data security and privacy issues and fail to focus on improving fairness in data sharing. To achieve anonymity and traceability of users, Huang et al. [7] utilized group signature technology in the proposed data sharing scheme without a trusted auditor by virtue of blockchain technology. Blockchain-based data sharing solutions are not only proposed in theory, but also play a significant role in solving difficulties in the life. To address the security and privacy concerns posed by electronic medical records, Chen et al. [23] proposed a signature based on antiquantum properties to share data securely with the blockchain. Tan et al. [24] proposed a blockchain-empowered solution that allows for direct tracking and revocation of medical records. To protect data privacy in building information model data sharing, Wang et al. [25] proposed a blockchain-based approach, which can used to secure information in the next generation of smart building industrial IoT. These schemes motivated the achieved property of user traceability and revocability in our proposed data sharing scheme.

To further enhance fairness in the data sharing process, a number of blockchain-based solutions and architectures [2628] have been proposed to ensure the security and fairness while implementing outsourcing services. Furthermore, Samuel et al. [8] presented a reputation system, fairly compensating through blockchain and differential privacy. In order to enhance the verifiability and fairness of cloud data management, Ge et al. [29] introduced a novel attribute-based proxy re-encryption scheme, according to which a concept called VA-ABPRE is defined and a concrete scheme is conducted. However, these schemes are constructed in the field of data outsourcing services while they cannot be directly deployed in microgrid. Wang et al. [9] applied blockchain technology to a supply chain to address issues such as distrust and asymmetric valuation of data that can arise from data sharing between upstream and downstream entities in the supply chain. But this study proposal uses an idealized model; actual supply chains cannot be completely adapted to it. Zhang et al. [30] introduced a data sharing scheme based on blockchain and ciphertext policy attribute-based encryption, where fair retrieval of ciphertexts is achieved through smart contracts. The editable blockchain in the authentication scheme of Zhai et al. [31] provided fine-grained and fair checksum functionality. Damisa et al. [32] proposed an Ethereum smart contract using a double auction mechanism to drive fairness and transparency in selection and compensation. The implementation of these smart contracts has effectively reduced the cost of manual intervention, where the property of accountability is not well studied [33].

8. Conclusions

In this work, we proposed a lightweight and privacy-preserving sensor data sharing system with attribute-based authorization in microgrid. In the system, we combined blockchain, smart contracts, and cryptographic algorithms (e.g., ABS, AES, and a lightweight signcryption scheme) to construct such sensor data sharing platform. Finally, we conducted a couple of experimental to evaluate the gas cost of functions in the smart contracts and general computational cost of cryptographic algorithms. To further improve the fairness of data sharing and running performance of the system, we continued to investigate the data pricing and claims mechanism, and moreover design a more lightweight cryptographic algorithm to replace the currently employed ABS algorithm.

Data Availability

No data were used to support this study.

Conflicts of Interest

The authors declare that they have no conflicts of interest.

Acknowledgments

This work was sponsored by National Natural Science Foundation of China (U1936213), Shanghai Rising-Star Program (no. 22QA1403800), Shanghai Sailing Program (no. 21YF1415000), and Program of Shanghai Academic Research Leader (no. 21XD1421500).