Abstract
This article introduces the new method of sensor data privacy protection method for IoT. Asymmetric encryption is used to verify the identity of the gateway by the sensor. The IoT gateway node verifies the integrity and source of the data, then creates a block, and submits the block chain transaction. In order to avoid tracking the source of the data, a ring signature is used to anonymize the gateway transaction. The proxy re-encryption method realizes the sharing of encrypted data. On the basis of smart contracts, attribute-based data access control allows decentralized applications to finely control data access. Through experiments, the effects of sensor/gateway verification, transaction signatures, and sensor data encryption on performance are discussed. The results show that transaction delays are all controlled within a reasonable range. The system performance achieved by this method is also relatively stable.
1. Introduction
Various sensors have penetrated into all aspects of our lives, and many of them are continuously collecting our information [1]. In this context, privacy issues related to the Internet of Things, especially consumer Internet of Things, have become the focus of attention from all walks of life [2]. As a kind of microcomputer terminal, the Internet of Things device exists independently of the computer network but is closely connected with the Internet [3]. Today, IoT sensors have penetrated into various industries, from industrial automation to medical equipment and then to the financial industry [4]. In short, there will be sensors wherever humans live [5].
Privacy protection is an important issue in IoT systems but has different references in different scenarios. For example, in the smart grid, the leakage of household energy consumption data and other information may cause hidden dangers to the safety of household personnel and property [6–8]. In smart medical care, the leakage of health data generated by patients’ wearable devices causes personal safety and ethical issues. Thus, following the above two cases, the privacy protection issue is considered related to the interests of the owner of the sensor data. This kind of privacy protection is called active privacy protection wherein the owners of sensor data have the opportunity to take necessary measures to protect their privacy [9, 10]. However, in public video surveillance applications, the privacy problem caused by face recognition is another situation. In this scenario, the issue of privacy protection is not an issue related to the interests of the owner of the sensor data (that is, the operator of the monitoring system) [11]. Whether to protect the privacy of the monitored person depends on the law and the level of the operator. Similarly, electronic license plate applications exist [12]. This kind of privacy protection is called passive privacy protection wherein the object whose privacy is compromised is powerless to solve this problem. For these two privacy protection problems, the problems to be solved and the directions to be considered are different. Thus, obvious differences are found in the solutions. For example, automatic coding method used in public video surveillance is rare in active privacy protection [13–15].
This article introduces how to solve the privacy protection about IoT sensor data based on blockchain [16]. The ring signature realizes the anonymization of gateway transactions, prevents data sources from being tracked, and solves the anonymization problem of blockchain-based IoT users [17]. Through asymmetric encryption, the sensor verifies the identity of the gateway and encrypts the sensor data [18]. The gateway can create a block and submit a blockchain transaction after verifying the integrity and source of the data. Finally, combined with data access control and data encryption sharing, decentralized applications perform fine-grained control over data access.
2. Method Architecture
The method architecture is shown in Figure 1. The system consists of sensors, gateways, blockchain, and various decentralized applications. First of all, the sensor and the gateway need to perform bilateral authentication, which can not only prevent the sensor from accessing the fake gateway, but the gateway also filters out offensive sensor data. After the identity verification is passed, Hash-based message authentication code is used to verify the source and integrity of the data collected by the sensor. The sensor uploads the data to the gateway. In order to protect the privacy of the sensor data, the gateway will first encrypt the data with a public key, use a ring signature to verify the anonymity of the transaction, and finally submit it to the blockchain. Based on smart contracts, an attribute-based control method is adopted. The encrypted data on the blockchain are decrypted and used by decentralized applications by proxy re-encryption.
2.1. Sensor-Gateway Authentication
To avoid the leakage of private data caused by the sensor’s access to the wrong gateway, this study adopts the Elliptic Curve Diffie–Hellman (ECDH) protocol combined with an asymmetric encryption method to realise the sensor’s authentication of the gateway’s identity and negotiate a shared key in the process.
ECDH is a variant of the Diffie–Hellman (DH) protocol that uses elliptic curve cryptography. The difference between the two is that ECDH is based on the elliptic curve discrete logarithm problem, whereas the DH protocol is based on the discrete logarithm problem. Similar to the DH protocol, the two parties in ECDH communication use their elliptic curve key pairs to negotiate a shared key on an insecure channel. This key can be used for the symmetric encryption of subsequent communications between the two parties. The negotiation process is shown in Figure 2.
The sensor and the gateway share a set of elliptic curve domain parameters . The sensor generates a random number , (), then the sensor sends to the gateway, and the gateway sends to the sensor. Finally, both parties obtain the same shared key (i.e., ).
The ECDH-based IoT device authentication to the gateway and the key negotiation process is shown in Figure 3.(i)The sensor side generates a random number , encrypts with the public key of the gateway, and sends it(ii)The gateway side generates a random number, , and sends back in plaintext(iii)If the sensor successfully parses out , the gateway identity is correct
The above process shows that, when the system is initialised, an ECC key pair needs to be allocated to the gateway, and the sensor needs to know the public key that it needs to access the gateway.
2.2. Sensor Data Encryption
The gateway creates and submits a blockchain transaction after verifying the integrity and source of the sensor data. To protect the privacy of sensor data when constructing a transaction, this article first uses the ECC public key to encrypt sensor data. The principle of public key encryption is as follows:(i)The 32-bit input data m are converted into point M on the elliptic curve, where f represents the selected elliptic curve equation:(ii)A random number is taken, where n represents the order of the selected elliptic curve equation.(iii)The first part C1 of the encrypted output is calculated, where G is the of the elliptic curve:(iv)The second part C2 of the encrypted output is calculated, where K represents the public key used for encryption:(v)The encrypted outputs C1 and C2 are obtained.
The process of decrypting with the ECC private key is as follows:(i)M is calculated according to the following formula, where k is the private key used for decryption:(ii)The original information m is extracted from M. For example, M is taken to obtain the x coordinate. The above process is only applicable to the encryption and decryption processing of the input message m with a length of 32 bytes. The message m of any length should be divided if the 32-byte fragments are viewed. The encryption process is performed on each fragment at a time, and the encryption result is obtained.
When decrypting, C1 is used to process sequentially and obtain the result.
2.3. Anonymization of Transaction Sources
To avoid tracking and identifying the source of the data (gateway), the Borromean ring signature method is used to anonymize gateway transactions. Ring signature is a special group signature method. The difference is that a ring signature does not require an additional group manager. With ring signature, the real signer can be hidden behind a set of public keys (address), thus realising the transaction anonymity of the true initiator.
Assuming that the message to be signed is m, the signer’s private key is , and the selected ring members are , the calculation process of the ring signature is as follows:(i)The hash of the message m is calculated as the symmetric key k as follows:(ii)The signer chooses a random value .(iii)The signer chooses a random value for other members (i.e., ).(iv) is solved, which makes the following formula true:(v)Signer trapdoor permutation and inversion are used:(vi)The ring signature is the output:
The equation calculated in step 4 can be shown in the figure below, where is the symmetric encryption function:
The verification process of the ring signature is as follows:
The equation can be expressed as a ring as follows:(i)Calculate as follows:(ii)Calculate the encryption key k as follows:(iii)Verify the ring equation as follows:
2.4. Sensor Data Shared
The encrypted sensor data can be decrypted and used by the encryptor. Third-party use must be considered in many cases. However, directly sharing the private key of the encryptor is not safe. Thus, this article uses a proxy re-encryption method to realise the sharing of encrypted data. The proxy re-encryption process is shown in Figure 4. In this article, the blockchain node acts as a re-encryption agent.
Users A and B hold key pairs and , respectively. User A uses his public key to encrypt the inscription data m to obtain the ciphertext on the chain. When user A needs to share his data with user B, user A generates a re-encryption key for user B and provides it to the blockchain node to re-encrypt the specified ciphertext to . After receiving it, user B uses his private key. The key can be decrypted.(i)b: user B’s private key(ii)a: user A’s private key(iii)q: order
Given that two sets of private keys are required to generate the re-encryption key and to avoid using B’s private key, user A needs to generate an additional temporary private key and provide it to user B after encrypting it with B’s public key.
To access the data of the specified sensor, decentralized applications need to request sensor data access permission from the gateway to which the sensor belongs, that is, to send the following message to the specified gateway. The fields of the message are shown in Table 1.
If the gateway agrees for decentralized applications to access the specified sensor, the gateway submits an authorisation transaction to the PAP contract on the chain, granting the requester the access permission to the specified sensor. The transaction parameters are as follows:(i)Target contract: PAP(ii)Contract action: grant(iii)Action parameters:(iv)Sensor: authorised sensor ID(v)User: requester ID(vi)Rk: re-encryption key generated for the requester(vii)Sk: decryption key generated by the requester, which is encrypted with the requester’s public key
After the transaction is confirmed on the chain, the pap contract is triggered to modify the access strategy of the specified sensor. The process is shown in Figure 5.
After the above transaction is confirmed, the requesting party can encrypt and decrypt the specified sensor data to obtain plaintext data. Decentralized applications request the latest sensor data by sending the following message to the blockchain node. The fields of the message are shown in Table 2.
After the node receives the above request, it will first check whether the requester has the permission to access the requested sensor. If the permission is granted, it will return the latest data (encrypted form) of the sensor and the key authorised by the gateway to the requester. The fields of the message are shown in Table 3.
The sequence diagram of the above process is shown in Figure 6.
2.5. Data Access Control
ABAC can finely control access to resources and mainly includes four components, namely, policy enforcement point (PEP), policy decision point (PDP), policy administration point (PAP), and policy information point (PIP). The data access process is shown in Figure 7.(i)PEP is responsible for receiving user requests, invoking PDP permission evaluation and determining whether to allow access to specified resources based on PDP evaluation results(ii)PDP evaluates the access request based on the rule base and returns the evaluation result (i.e., denying or allowing access)(iii)PAP is the management interface of rules provided for administrators, such as adding new access policies and updating designated access policies(iv)PIP provides out-of-core attribute information for PDP
3. Experimental Evaluation
3.1. Verification of Encrypted Data Utilisation Process
The experimental configuration is as follows:(i)Synthesis of sensor data: open(ii)Verification of sensors and gateway devices: open(iii)Encryption of transactions: open(iv)Data encryption method: ECC
The data chaining process in the experiment is described as follows:(i)The sensor verifies the identity of the gateway and negotiates a shared key(ii)The sensor submits data to the IoT gateway(iii)The IoT gateway node verifies the integrity and source of the data and rejects the data if the verification fails(iv)The gateway encrypts sensor data, generates new transactions, and performs ring signatures(v)After the blockchain node verifies that the transaction is correct, the node will queue the transaction up in the buffer pool(vi)Blockchain nodes generate blocks to confirm transactions
The access authorisation process in the experiment is as follows:(i)The gateway submits an authorisation transaction to the blockchain node and grants the data access rights of 80000# sensor to decentralized applications.(ii)Decentralized applications regularly submit query requests to blockchain nodes and obtain encrypted sensor data and the proxy re-encryption group.(iii)Decentralized applications perform re-encryption first, decrypts the data, and displays the decrypted plaintext. The experimental results are in line with expectations. The screenshot is shown in Figure 8.
3.2. The Impact of Encryption on Performance
The program is implemented in Python language, and the experiment is mainly carried out in the following aspects: the impact of transaction signatures on performance and the impact of sensor data encryption on performance.
The system has set up 50 sensor nodes, 10 gateways, and 4 blockchain nodes. The system can set parameters in advance, set the block generation cycle of the blockchain node to 5 s, set the sensor report data cycle to 1 s, enable sensor data integration, configure whether to verify the sensor/gateway, and configure transaction signatures and sensor encryption methods.
3.2.1. The Impact of Transaction Signatures on Performance
We use different signature methods to discuss the impact on system performance. The parameters are as follows:(i)Cycle of block generation: 5 s(ii)Cycle of sensor data submission: 1 s(iii)Synthesis of sensor data: open(iv)Verification of sensors and gateway devices: close(v)Encryption of transactions: close(vi)Data encryption method: none/ECC/ring
The transaction delay time statistics of the no-signature method and the ECC signature method are shown in Figures 9–12
Figures 9–12 show the influence of ECC signature on transaction delay time. When no signature is added, all transactions are confirmed within 5 s of the block generation period. When the ECC signature is added, the maximum transaction confirmation time is delayed to more than 7 s. That is, given that ECC signature requires a certain processing time, the simulation system has been overloaded when the block generation period is set to 5 s. When the ring signature method is used, this overload phenomenon is more obvious because the ring signature requires more processing time. Figures 13 and 14 show that the maximum transaction delay time has exceeded 20 s.
The block generation period is set to 30s, and the experiment of the ring signature method is re-run. The results are shown in Figures 15 and 16
The transaction delays are kept within the block generation period, and the system is operating normally.
3.2.2. The Impact of Sensor Data Encryption on Performance
Sensor data encryption and nonencryption methods are used to investigate the impact of this link on performance. The experimental parameters are as follows:(i)Cycle of block generation: 5 s(ii)Cycle of sensor data submission: 1 s(iii)Synthesis of sensor data: open(iv)Verification of sensors and gateway devices: close(v)Encryption of transactions: close(vi)Data encryption method: none/ECC/ring
The experimental results are shown in Figures 17 and 18.
Figures 17 and 18 show that the encryption of sensor data has little effect on transaction delay. Figure 17 shows the corresponding transaction delay histogram statistics and transaction delay cumulative ratio statistics when sensor data encryption is not enabled. Figure 18 shows the statistics of the transaction smoking, eating, and releasing graphs and the cumulative ratio of transaction delays after the sensor data encryption is turned on. In Figures 17 and 18, the blue histogram counts the number of transactions that fall in each delay interval, and the red line graph calculates the proportion of the number of delays corresponding to the current interval in the total number of transactions, which we call it the cumulative proportion of delay in this interval is displayed on the ordinate on the right. From the two figures, we can see that after the sensor data encryption is turned on, it will affect the total number of transactions. As can be seen from Figure 18, the number of transaction delays in each interval has been reduced. However, after the sensor data encryption is turned on, the transaction delay time will not be affected. From the red line chart, we can see that all transaction delays are still below 5000 ms, and the cumulative proportion accounts for almost 100%.
4. Conclusion
This article introduces sensor data privacy protection method for IoT based on blockchain technology. The ring signature realizes the anonymization of gateway transactions, prevents data sources from being tracked, and solves the anonymization problem of blockchain-based IoT users. Through asymmetric encryption, the sensor verifies the identity of the gateway and encrypts the sensor data. The gateway can create a block and submit a blockchain transaction after verifying the integrity and source of the data. Finally, combined with data access control and data encryption sharing, decentralized applications can finely control data access. Through experiments, the impact of transaction signatures on performance and the impact of sensor data encryption on performance are analyzed. The results show that transaction delays are all controlled within a reasonable range. The system performance achieved by this method is also relatively stable.
Data Availability
The data that support the findings of the research are available from the corresponding author.
Conflicts of Interest
The authors declare that there are no conflicts of interest.
Acknowledgments
This work was supported by the Key Research and Development Plan of Anhui Province (201904a06020056). The authors are very grateful for the research foundation of the conference paper “IoT Data Privacy Protection Scheme Based on Blockchain” in IOP Science.