1. Introduction
In recent years, the term IoT has become popular all over the world, inciting the attention of researchers from different areas. One of IoT main goals is to make the Internet even more immersive. Also, by facilitating access to a wide range of devices such as appliances, surveillance cameras, monitoring sensors, actuators, vehicles, and others; the Internet becomes more interactive. According to [
1], by 2020, 50 billion devices will be connected to the Internet. Thus, IoT will enable the development of different applications that make use of the data generated by such devices to provide new services to citizens, businesses, and governments. However, connecting these devices still be one of IoT biggest challenges. According to [
2], the use of centralized architectures still popular today, with authentication, authorization, and connection of devices; This model is sufficient for the current development of IoT, however, with their growth, these systems will need more investments, and entire systems could be damaged if the centralized point of the architecture becomes unavailable.
Considering the centralized architecture model, in addition to scalability issues such as IoT growth, there are still security, privacy, and failure issues. These problems occur due to centralized architectures run services on a single point of the network. The moment that the single point fails, the entire system is compromised. Nowadays, there are various proposals for centralized architectures for IoT environments. The work proposed in [
3] describes a software-defined device-based centralized architecture for IoT environments. In the work presented in [
4], the authors describe a centralized architecture using Fog-to-Cloudlet-to-Cloud Data Management in Smart Cities. In [
5], the authors propose a centralized clustering-based architecture for communication between smart homes. However, as mentioned earlier, centralized architectures are vulnerable to different issues that can compromise the system. The privacy leak problem can be considered one of the most dangerous in this type of environment.
With a massive amount of data generated in IoT environments, different privacies may exist. Four main concepts define privacy, they are information privacy, body privacy, the privacy of communication, and territorial privacy. The work proposed by [
6] shows an architecture that manipulates privacy at different levels. This approach is ideal for IoT environments, given a large number of devices connected in different environments by multiple users. However, addressing privacy at different levels using centralized architectures becomes problematic due to the unique points of failure in this type of architecture. This approach requires the use of a decentralized and robust technology that can solve the privacy problem completely, thus ensuring the proper functioning of IoT applications.
In 2008, Nakamoto described the blockchain concept through the Bitcoin cryptocurrency [
7]. Blockchain is a decentralized technology that ensures the integrity of transactions performed on the platform without the need for validation by a third party. The blocks store the transactions done and link to each other through a hash function. A consensus algorithm, also called mining process, calculates the hash of each block. The mining process varies for each blockchain. Altering a block maliciously will compromise all other existing blocks in the chain, then all blocks need to be re-mined to be valid, making the process of hacking a blockchain unfeasible. Other applications than cryptocurrency can benefit from the blockchain technology. Over the years, different blockchains came up with different proposals for different scenarios. One of the most promising blockchains is the Ethereum network.
Vitalik Buterin proposed the Ethereum platform in 2013 [
8]. Ethereum platform is a decentralized network able to execute smart contracts. These are programmed scripts that work as programmed, without the possibility of fraud, censorship, or alteration through third parties. Due to this functionality, this platform has proved to be revolutionary for the development of decentralized applications. Diverse decentralized applications are proposed using the Ethereum platform, as examples are marketplace [
9], e-voting [
10], smart grid [
11], social networks [
12], smart home [
13], e-health [
14], fake news detection [
15], and others. Considering this, it is clear that the Ethereum platform is viable for the development of IoT applications of various types due to its functionalities.
Considering this context, we propose an architecture that uses the Ethereum platform for privacy management in IoT environments. In our architecture, we use smart contracts to manage privacy at different levels for different profiles. We chose to use a gateway to manage device-user communication, considering the scalability of the network. The scenario chosen for testing was an educational environment in different situations. We developed a decentralized mobile application to prove the efficiency of the proposed architecture.
This paper is structured as follows.
Section 2 presents the background necessary for understanding the proposed architecture. In
Section 3, an analysis of related work is done, considering the privacy management in IoT environments. In
Section 4, we describe the proposed architecture.
Section 5 describes the tests done and the results obtained. Finally,
Section 6 presents the conclusions obtained from the development of this work and the suggestions for future work.
3. Related Work
This section shows the related work identified. In the analysis, we attempt to identify in the works listed, how each of the authors treated the privacy preferences of the user, environment, and device. We studied how each of the references dealt with the use of blockchains for scalability and network performance. Also, we observed how the authors addressed the storage of data acquired in each application. At the end of this section, we make a comparison between the identified related works and the proposed architecture in our work, trying to present the advantages of our work about the architecture proposed by other authors.
The work presented in [
30] shows the idea of using gateways combined with smart contracts for privacy management in IoT environments. The architecture presented addresses user and device privacy, this happens because the user has privacy preferences registered in one smart contract, and the device preferences are registered in another smart contract. Device-user communication is done through a gateway that is also responsible for executing the blockchain privacy preferences register. For the development of the tests, the authors used a private blockchain built in the Ethereum network. The main critique of this work concerns the registration of privacy preferences in the blockchain, the gateway is used to perform this role, but any failure or malicious access to the gateway could alter existing privacy preferences or register malicious devices in the blockchain network.
In [
31], the authors describe a blockchain architecture directed at handling device information and registration in IoT environments. The privacy approached at work refers to the user, who can register through smart contracts their devices, access policies, transactions with other devices, and other features. The authors illustrate an utterly decentralized architecture where, according to them, there is no need for hardware to assist in device-user communication. To be able to exercise communication in a completely decentralized way, the authors report using the Proof-of-Authority consensus algorithm. Data storage is done off-chain through the IPFS protocol. The blockchain used in the tests was the Ethereum blockchain. The main critique regarding this work refers to the use of the Proof-of-Authority consensus algorithm, which is valid only in implementations in which there is a processing node. The authors use more than one processing node in their architecture. The validation of the implementation is not confirmed since no tests are presenting the algorithm.
The work of [
32] proposes a blockchain architecture for IoT environments focused on off-chain data storage using the IPFS protocol. The authors define device privacy through smart contracts that store information such as the cryptographic keys of each device, the devices that are allowed to communicate with the blockchain, and others. This structure ensures device privacy, as a specific environment can have a blockchain (sidechain concept), so each can have different privacy rules and policies. In the tests was used a consortium blockchain built in the Ethereum network. In this work, the negative aspect observed was the number of transactions performed per minute on the blockchain, the authors report the use of 97% of the validation node processing power to reach 300 transactions per minute on the built blockchain for the tests.
The work presented in [
33] consists of using blockchain in smart homes, focusing on the privacy of the devices in this type of environment. The privacy addressed at work regards about devices, where through different smart contracts (access control, decision making, and registration) the privacy preferences of each device are controlled and set. In each smart home, a gateway is used to communicate with the blockchain. According to the authors, IoT devices do not have the computational power to communicate directly with the blockchain, so it is necessary to use a gateway to perform this communication. The authors developed the tests on a private blockchain built on the Ethereum network, storing data off-chain through a cloud service. The main critique of this work is that the results obtained show only the functionality tests of smart contracts, disregarding the gateway performance.
In [
34], the authors aim to ensure privacy about the IoT data, for which the authors propose a framework using blockchain. In this paper, the privacy of the devices is addressed using smart contracts. Three different contracts (privacy setting, owner, and privacy policy subscription) are used to address the privacy mentioned. The gateway is used to communicate devices with the blockchain. The authors decided to use a gateway because of the performance characteristics of this hardware over IoT devices. The work uses two blockchains, one public and one private, responsible for controlling transactions between different devices in different locations and allowing the user to control their own devices, respectively. The Ethereum blockchain was used to implement the proposed framework. Data generated by IoT devices is stored off-chain. The main critique regarding this work is the cryptographic key registration; the gateway is responsible for doing this process. If an attacker has access to it, can generate keys for devices that should not belong to the network.
The work of [
35] proposes a decentralized architecture focused on IoT environments using smart contracts to ensure autonomy on device communication. The work addresses device privacy, where a smart contract is generated for each device, allowing to define different functions for each device registered in the network (here it is mentioned that each device has a contract with unique functions, being different contracts for each device due to its characteristics). The proposed architecture uses no gateway. In the tests made, the Ethereum blockchain was used. The data storage is done off-chain through a clouding service. The main critique about this paper regards to network performance, considering that there will be a large number of transactions, it is not possible to identify in the authors work, how blockchain can handle a large number of transaction requests between connected devices.
The work presented in [
36] aims to transfer the right of access to devices in a decentralized way. The authors propose the use of Tangle technology, present in IOTA blockchain. The privacy addressed at work concerns about the user, where the user sets his privacy preferences and distributes the privacy preference to another user through a token. The user will only receive the token if its features meet the privacy preferences of the token owner. IOTA blockchain offers performance and scalability advantages, so no gateway was used. The main critique regarding this work is privacy issues. The work does not discuss in detail how the privacy policies of users are stored. Compared to other works, we could not identify how that same architecture could treat other types of privacy (e.g., environment and device).
The work of [
37] proposes privacy protection through the use of different blockchains to prevent transaction tracking attacks. The privacy mentioned by the authors regards to user’s privacy, which, through their shared information, may allow someone to find out their location by tracking the transactions stored in the blockchain. Different private blockchains are used to redistribute the transaction made by the user across different networks. The public blockchain is used to initiate the transaction process between two network users. The authors do not use gateways in their work. The main critique about this work is the cost of implementing the solution proposed by the authors for other scenarios since different blockchains are present in this architecture.
The work proposed in [
38] uses a different blockchain model for IoT environments by eliminating the PoW consensus algorithm. In order to ensure privacy, the authors propose a lightweight privacy-preserving ring signature scheme. The privacy addressed at work resides in the user and device. The authors use an encryption method combined with a digital signature to ensure privacy. The authors do not present any gateway in their implementation due to the optimization of the consensus algorithm. The blockchain used is public. The data is stored off-chain in a cloud service. The main critique about this work is the use of smart contracts only for information verification of IoT devices.
Table 1 summarizes the information obtained in the analysis. The items showed in the table illustrate if the work addresses a specific aspect of the work. If the work does not specify any of the items, we used NE to denotate that. The table is divided into eight columns, as described below:
4. Proposed Architecture
Figure 5 illustrates the architecture overview. We divided the architecture into three layers called the blockchain layer, communication layer, and application layer. In the blockchain layer, smart contracts are stored, and transactions made in the environment are validated, in this layer, devices with considerable computational power are used to process blockchain requests. The communication layer is responsible for managing device-user communication. For this, a gateway is used considering that IoT devices do not have enough computational power to communicate directly with the blockchain. Finally, the application layer consists of the environment, user, and device, in which each will interact with each other through the decentralized mobile application developed. This layer also includes the IPFS storage service for data storage.
Considering the architecture illustrated in
Figure 5 and the middleware described in
Section 2, PRICHAIN is a decentralized implementation of UbiPri middleware. Using smart contracts combined with the communication gateway and IPFS storage service, PRICHAIN ensures the functionality of UbiPri modules. The use of different smart contracts, one for the environment, one for device and one for the user, favors the implementation of UbiPri in a decentralized way. The decentralized IPFS storage service and communication gateway assist in the implementation of the other middleware modules.
4.1. Smart Contracts
As mentioned previous, one of the UbiPri middleware assumptions refers to the concept that the environment denotes privacy rules. Therefore, we chose to use a smart contract specifically for the environment. The user has a separate smart contract with its individual privacy preferences. This decision was made as the user may not agree with the environment rules. Finally, devices (sensors and actuators) also have smart contracts with their privacy preferences.
Figure A1,
Figure A2 and
Figure A3 illustrate the contracts developed, the contracts were based on the proposed implementation in [
39].
4.1.1. Envinronment Smart Contract
The Environment contract has a rule structure based on an identification string, a rule description string, and a byte field of values. The user can also set a value for the permission level required to interact with the environment, and whether or not the environment will require access to user data history. The User contract has a structure of privacy options, also containing identification and value fields. The user can set the access level, such as whether or not they will allow access to their data history. A method called connectToEnvironment() requires the address of an Environment to verify that privacy, access level, and data usage options are compatible across contracts, returning incompatible items if any. The connectToDevice() method performs the same operations but based on a list of devices present in the environment, where the user can discover services. Pending operations framework store incompatible privacy options, which the user can apply if he/she agrees with them. Before each exchange, the old privacy values are stored in a backup structure so that the user can return them at any time. Finally, the Device contract also has a list of required privacy, permission to use user history, and required permission level. Also, the MAC address of the physical device is stored by the contract, which will be returned if the user can successfully connect to the device.
4.1.2. User Smart Contract
The user can communicate with an environment by providing their address as an argument during a connectToEnvironment() operation. From this, the compatibility between user preferences and environment rules will be tested as well as the required permission level. In case of mismatch, Blockchain will return a list of frames including the name and value of missing or mismatched preferences, as well as the number of items in that list and a logical value indicating whether the operation was successful or not. In the case of compatibility, the environment contract will pair with the user contract in case of compatibility.
4.1.3. Device Smart Contract
Being connected to the environment, a list of devices will be available in the contract and presented to the user. The user, in his contract, can enter as an argument the target device address within the connectToDevice() function. All preferences, as well as the required permission level, will also be tested by returning, in case of failure, the incompatible preference list, list size, valid value operation code, and null MAC address. If the communication is successful, the Android app redeems the corresponding MAC address of the device.
Figure 6 illustrates the sequence diagram of communication between user and environment, described at the beginning of the section.
Figure 7 illustrates the sequence diagram of communication between user and device, described at the beginning of the section.
4.2. Communication Gateway
The gateway mediates communication between the user and the device. The communication protocol adopted was CoAP, using the library CoAPthon3, for the Python language. All operations performed are based on the resources available through the gateway. A device may perform a POST operation to provide a new service (or feature) that is identified by concatenating its MAC address with the type of service offered (e.g., CA: FE: CA: FE: CA: FE-LED).
Thus, a device can be configured to update a resource with the values of a sensor, or perform a periodic GET on a resource to obtain its value, as in the state of an LED changed by the user. When one of the points operates with PUT, the gateway reads the source, target MAC address, and communication data. This read information will be immediately sent to an IPFS node using ipfs-API, where it will remain unchanged. The user will be able to connect to a device resource via the MAC returned from the pairing function available in Smart Contracts, which concatenates with one of the discovered services names.
4.3. Mobile DApp
Dapps or Decentralized Application arising from Ethereum platform and their main objective is decentralization. For this, a dapp application must have the following principles:
The application must be completely open source, it must operate autonomously and with no entity controlling most of its tokens.
The application may adapt its protocol in response to proposed improvements and market feedback, but all changes must be decided by consensus of its users.
Application data and operation records must be stored cryptographically in a decentralized public blockchain.
Use a token that is required to access the app and any important contributions should be rewarded with the app tokens.
The application must generate tokens according to a standard cryptographic algorithm that acts as proof that the nodes are contributing to the application.
As proof of concept and validation purposes of the proposed architecture, a smartphone application was developed using the Web3 library based on the React platform. The web app written in JavaScript and HTML5 provides the user interface for the Ethereum client, which in turn interacts with the blockchain.
The main purpose of this application is to interact with the three smart contracts (User, Environment and Device) mentioned above.
Figure 8 represents the login screen for the application user to control the environment, the menu with available options and finally the list of available environments for user interaction.
5. Tests and Results
The hardware used was a 16-bit Arduino Uno R3 architecture operating at 16 MHz and 2 KB SRAM along with Ethernet Shield W5100. The sensors used were a 16-bit DHT11 resolution to measure temperature and humidity and an HC-SR04 ultrasonic sensor to check for the presence of people in the environment. A notebook with a 4-core Intel Core I5 8265U Dell notebook and eight threads operating at 1.6 GHz with 8gb DDR4 RAM and a 64-bit Kubuntu 18.04 operating system hosted the gateway and IPFS service. CoAP communication on Arduino was implemented through the SimpleCoAP library available on the Arduino IDE library manager.
The sketch used in Arduino occupied 19,998 bytes of the 32,256 bytes of available flash storage. It did not use EEPROM storage and 785 bytes of 2048 of available dynamic memory on the device representing 38% of the total. A local network simulated the environment. Therefore the latency of transmission by the network was disregarded.
The Ropsten TestNet was used as a private blockchain to test the interaction between and with contracts at no production cost. The average time to mine a block is 15 s, its standard gas price is 4 GWei, and the gas limit per block is 6,721,975.
5.1. Blockchain Performance
Table 2 shows the cost of implementing each of the three contracts in the network, considering a gas price of 20 GWei, which is the default for contracts due to the speed required in the transaction.
We note that the complexity of the logic of each contract contributes greatly to its cost. The User contract is the most complex and costly because of the functions that pair it with Environment and a Device, which instantiate other contracts, compare preference structures, store data, and access lists. On the other hand, Environment and Device contracts are logically simple and similar, which contributes to a relatively low cost. In
Table 3,
Table 4 and
Table 5 some methods of each contract were chosen for further cost analysis based on their recurrence in normal use of the architecture.
As seen, the most costly functions are those that deal most with memory access, such as applyBackupPrefs() and applyPendingPrefs(), which deal with the user preference list. Although the connectToDevice() and connectToEnvironment() functions are logically more complex, computationally they are the least expensive.
In the Device contract, only one function has been tested, which is the most relevant to the architecture. This function only handles a six-position byte array and is therefore not as expensive.
Again, the most expensive functions presented, such as setRule() and setDevice(), are those that most interact with lists. On the other hand, functions that only change a single contract value, such as setDataAccess() and setPermLevel(), have a low cost.
5.2. Gateway Performance
Four distinct classes divide the tests about the implemented Gateway: Processing Time, Device Request Time, User Request Time, and IPFS Insertion Time. The operations performed and measured were those of GET and PUT, due to the consequence of their use in communication. The message size chosen was 4 bytes, as it is an average payload of all environments defined for this article. However, the IPFS node will receive the message along with the source MAC and request MAC target, totaling 38 bytes for its specific communication. The number of samples is 1, 10, and 100 shipments. In
Table 6, we can see some of these results for the PUT method.
User request time was the longest among them due to internal network latency, machine-to-machine communication time, and gateway processing time. For the gateway, a PUT operation takes the most processing time because of the need to read the payload and update the CoAP resource. The device request time remained stable throughout the test. IPFS insertion, which counts the time of local node communication and message transfer, was the least expensive of the steps involved.
Table 7 shows the same results for a GET operation, however without the IPFS insertion time, which is a characteristic of the PUT operation only.
5.3. Privacy
Figure 9 illustrates a user’s communication with the DHT11 sensor. User privacy preferences satisfy environment and device privacy preferences. Thus, the user can connect to the device and get the data related to it.
In this situation, the user also chose to store the communication data.
Figure 10 illustrates the gateway’s connection to the IPFS service.
Figure 11 shows a user attempt to interact with the HC-SR04 sensor, but in this situation, the user’s privacy preferences do not match the device’s privacy preferences, so attempting to establish communication with the sensor is declined by blockchain.
5.4. Security
For security testing, communication with a local IPFS node has been established. According to its operation, recorded in a CoAP (PUT) resource is transferred from the IPFS API. The called function reads the message content and concatenates it with the MAC address of the source and target device. IPFS generates a hash about this message. Each hash generated corresponds to an address with immutable content within the network. Due to that, no transaction data will be improperly changed. The work aimed at abstracting the functioning of IPFS and, therefore, the address is not returned and saved in the user contract, but there is the possibility of an easy implementation of this mechanism.
6. Conclusions and Future Work
In this paper, we present a blockchain architecture for use in IoT environments. The UbiPri middleware, which the central objective is the privacy treatment in IoT environments, was used as a basis for the proposed architecture. We use a decentralized application to make the interaction between user, environment, and device. We can also ensure privacy at different levels by generating different smart contracts. Due to scalability issues, we chose to use a gateway for device-user communication. To ensure the integrity of stored data, we use the IPFS service, also ensuring data security.
With the tests developed, we realize that the architecture proposed in this work is feasible for implementation in different IoT environments. The results obtained concerning smart contracts show that the complexity of the contracts directly influences its cost. The User contract has the most functions, consequently being the most costly contract. Regarding the gateway, we realize that the results show that the implementation is scalable even with the latency generated by machine-to-machine communication and gateway processing time. In the privacy tests developed, we note that user-defined preferences are satisfied, however, when a user does not agree to change their privacy preferences to suit their environment, they cannot communicate with devices, smart contracts proprieties guarantees the privacy preferences. Regarding security, the integrity of the data stored in the IPFS service is guaranteed through a hash function. However, in this article, we aimed to abstract the IPFS service.
The results obtained with the development of this work contribute to other research that is being developed in the area of privacy. The use of the Ethereum blockchain has shown different costs for each contract. We can emphasize that they can be adapted to other types of blockchain. The design of the contracts was based on different state-of-the-art solutions. Therefore, this work also contributes to several areas of IoT that use smart contracts.
For future work, we suggest optimizing the contracts developed to reduce their cost. Regarding the gateway, we suggest the study of new technologies that can eliminate its implementation in the proposed architecture, making it completely decentralized.