LoRaTRUST: Blockchain-Enabled Trust and Accountability Service for IoT Data

Abstract

Environmental monitoring is a growing application of the Internet of Things. The low cost of the sensor nodes, LoRa connectivity, and increased awareness of environmental issues have motivated many citizens to participate in open IoT monitoring applications. However, the value of these applications for decision makers is limited since the data from the IoT sensors do not have sufficient guarantees to be trusted. In this paper, we introduce a new concept that attributes value to both IoT data and devices, such as sensor nodes and gateways, and leverage distributed ledger technology to enable a data trust system. A first design decision was to assign Ethereum addresses with their associated public and private key pairs to all actors. This allows the authentication of data senders and hence the accounting for the contribution of each participant. Secondly, we introduce an auditor to validate the received IoT data. The results of these audits increase the trust in the quality of the data. We present the architectural components that we designed to enhance trust in open IoT monitoring applications and present an operational prototype to show the feasibility of the implementation. By achieving both trust in the data and accounting of contributions for giving rewards, open participatory IoT monitoring applications can become both valuable and sustainable. Then, trusted open monitoring may complement commercial solutions as a technical and economic alternative for addressing the increasing environmental monitoring needs of our society.

1. Introduction

Environmental monitoring is an expanding application of the Internet of Things (IoT) due to the need to detect and address environmental impacts at their early stages. Smart cities use environmental data to optimize resource allocation through predictive models and to conduct environmental risk assessments [1,2]. IoT technologies have the potential to support environmental impact management, conservation, public participation, and evidence-based policymaking.

IoT monitoring applications are typically full-stack software that integrates sensor nodes for taking measurements at remote locations with a cloud-based backend. LoRa, a low-power, long-range communication technology, is a widely adopted solution for transmitting the data from the sensors. In the often used LoRaWAN architecture, sensor nodes transmit data with a one-hop distance to a gateway. From the gateway, the data are then sent to cloud-based services, where data are managed, analyzed, and delivered to end users through dashboards [3].

Two types of provisioning such IoT environmental monitoring applications can be distinguished: centrally managed and open participatory monitoring, often related to a citizen science approach [4]. In the centrally managed type, the entity that operates the IoT application follows agreed rules in terms of data acquisition and sensor node hardware [5]. Therefore, the end user can trust the delivered monitoring data. Differently, if the application is open for participation where the monitoring data and sensor nodes are jointly provided by multiple untrusted parties, then the trustworthiness of these is hardly guaranteed. For instance, citizens may acquire affordable sensor nodes without fulfilling the required calibration, or monitoring data may be tampered [6].

While the centrally managed type provides trusted data, it also has an economic cost and is not always affordable for many of the stakeholders, such as communities of citizens, regional governments, or smaller municipalities. Thus, it may be beneficial for stakeholders to consider the complementarity of the second type, citizen-provided data from open participatory monitoring applications for contributing to the public IoT infrastructure [7].

For many IoT monitoring applications, however, the trustworthiness of the data is a critical property for the data to be of value. However, once trust is provided for the measurements of citizen-provided IoT devices, as well as incentives for citizens to participate, then the usefulness and spread of open participatory IoT monitoring applications could be catalyzed.

Figure 1 sketches the effects that a trust provider with a verifiable registry could have on trust in open participatory IoT monitoring applications. In order to obtain data, the IoT application needs two types of contributions from the citizens. First, contributions of data, which are obtained from citizens deploying sensors and generating data, and second, contributions of resources, which consist of hardware such as gateways that citizens deploy to enable the connectivity of the sensors for transmitting their data to the Internet. When sensors and gateways operate, the IoT application collects sensor data and information about the gateway involved in the data transmission. The question arises, how can these citizen-provided IoT data be enhanced with trust. A blockchain-based registry implemented as a smart contract could allow any interested parties to verify that the data collected by the IoT application comes from registered devices (sensor and gateway nodes). For this, the verifiable registry collects information (public keys and node metadata) about all the sensor and gateway nodes that operate in the system. This allows, through the registry, to verify the collected data in terms of origin and being untampered. The verification also allows the accounting of contribution (of monitoring data and gateway provision), since the relation of the devices and their owners can be verified by the on-chain information stored in the smart contract. This verification increases the trust in the correctness of the IoT data, thus making the data valuable for the decision maker. Once the data have an impact, the application user, e.g., a municipality, is willing to provide incentives for citizens to make data and hardware contributions, thus making these open participatory IoT monitoring applications sustainable.

Trust in IoT systems has been receiving increasing attention from the research community, as shown in the recent survey by Fotia et al. [8]. In their work, solutions for decentralized trust management using blockchain are extensively discussed. Smart Contracts (SCs) are highlighted as a mechanism to supply IoT functions with authentication and to authorize devices. The verification of data and access control to data is another function that can be enabled by blockchain and to which smart contracts can contribute. The authors remark that IoT systems split into three layers, i.e., a physical perception layer, a network layer, and an application layer, require trust to be assured on all three layers to generate trustworthiness.

A recent survey on IoT security by Noor et al. [9] lists the challenges and vulnerabilities of the IoT layer and current solutions to diverse threat vectors. Key-based authentication and encryption are widely used means for identifying devices, authorizing access, and guaranteeing the confidentiality of data. For IoT devices, a challenge is their resource constraints that may limit security options to lightweight solutions. Another difficulty in implementing common solutions lies in the heterogeneity of IoT devices and different communication protocols. Given these limitations for applying classical security solutions to the IoT, the body of work on trust-based solutions has grown. In trust management, the focus is on detecting a malicious node from its behavioral pattern and complementing the authentication-based methods. Trust management leverages additional services. For instance, trust scores for the nodes can be obtained from a machine learning model. In addition, the authors point out blockchains as a new technology for identifying nodes and creating secure zones where all actors can trust each other.

In this paper, we present LoRaTRUST, an open participatory IoT application for environmental monitoring that integrates a blockchain-based verifiable registry to enhance trust in IoT data and sensor nodes of a LoRa-based IoT communication layer. The registry is materialized as a smart contract to which trusted providers can write metadata about the IoT devices and, hence, make these devices eligible for being used in the applications. Such metadata includes the identity of the device, but can be extended with the device owner, device configuration, and more details such as the hardware specifics of the board and sensors. This metadata is used to verify the data origin and data quality of received sensor data. We develop the LoRaTRUST architecture and a prototype implementation. LoRaTRUST is a full-stack application that spans from the sensor hardware to the end user web interface (Figure 2).

We aim to achieve that the IoT data of open applications can become trusted, by data verification, and that data generation and hardware provision are recognized, by accounting for the contributions. We demonstrate how the architectural components are supported by a smart contract in the blockchain to deliver trust in the sensor data and metadata of the IoT devices. The novelty of our approach consists of the combination of both trust in IoT data and trusted accounting for the reward of contributions.

The main contributions of this paper are:

• We design the architectural integration of a blockchain-based verification system, which verifies IoT device attributes to enable trust in data and accounting in open IoT applications.
• We present a prototype implementation that demonstrates the practical feasibility of this integration.

The methodology we use to elaborate these contributions is to derive the architectural components from the requirements of use cases and to build a prototype for all architectural layers to demonstrate the implementation feasibility. The Internet-hosted components of the prototype are deployed on a publicly accessible website (https://demo.loratrust.com/demoProfile/, accessed on 1 March 2023). The developed code is publicly available in an open Git repository (https://codeberg.org/LoRaTRUST, accessed on 1 March 2023) to enable reproducibility.

2. Background and Related Work

Open environmental monitoring systems can be considered a kind of participatory sociotechnical systems. In order to be valuable and sustainable, these systems need to have two properties. First, they need to deliver trusted data, such that the information they provide is of value. Second, they need to reward participants in order to motivate these volunteers to continue contributing to the system.

2.1. Participatory Systems with Rewards and Support from the Blockchain

There are nowadays several operational applications organized as participatory systems that account for the contributions of their participants. For instance, GridCoin (https://gridcoin.us/, accessed on 1 March 2023) [10] rewards the contribution of CPU cycles to volunteer computing tasks. FileCoin (https://filecoin.io/, accessed on 1 March 2023) [11] incentivizes the contribution of hard disk space. These contributions enhance the service’s reliability and redundancy. The concept is that third parties can contribute to a participatory system, then the system measures this contribution and the amount of the contribution is rewarded. In both systems, GridCoin and FileCoin, users have to trust the blockchain and blockchain technology is used to manage the participation and rewards.

Incentivizing the provision of IoT hardware, specifically gateways, is the objective of the Helium network [12]. Different from the previously mentioned examples, in which computing resources are contributed at the exchange of coins, in Helium, the contributions are LoRaWAN gateways. This leads to the aim of Helium to become a global network of LoRaWAN gateways. Then, this network will offer coverage for any IoT sensors to reach the Internet by sending data in LoRa packets to the Helium gateways. In this context, it is necessary to point out that LoRa is a technology that does not need any license or network operator, different, for instance, from other Low Power Wide Area Network (LPWAN) technologies such as NB-IoT or Sigfox. Therefore, LoRa networks do have the potential to grow organically with contributions from everybody, such as exemplified in Helium.

Dimitriou, in [13], presents a rewarding framework for crowd-sensing applications, which enables users to submit data and receive Bitcoin payments in a privacy-preserving manner. The protocol ensures the fairness of the exchange and prevents malicious user behavior, such as double-redeeming attempts. The blockchain represents a trusted third party that replaces traditional third parties in fair exchange protocols.

Mobile Crowd Sensing (MCS) leverages the sensing capabilities of smartphones and the power of the crowd to collect data. PaySense [14] incentivizes user participation and links the quality of collected data to the users’ reputation. The framework utilizes the Bitcoin cryptocurrency to perform all features in a privacy-preserving way. Our rewards are non-monetary and off-platform to discourage cheating, and we incentivize both sensor measurement contributions and IoT device contributions.

Incentivizing decentralized federated learning frameworks has been surveyed in [15]. The concept of this scenario is similar to that in the present paper on data contributions from the many participants in open IoT monitoring applications, since federated learning models can be built collectively as a joint effort of independent entities. The work focuses on how blockchain technology is used for both enabling a decentralized architecture of federated learning frameworks and as a means for managing accounting and incentives. Similar to IoT data contributions, there is the issue of trust in the federated learning model provisioned by each participant. The survey does not elaborate on the specific challenge of trust but identifies a lack of production readiness of current works and a lack of a common system model and architecture.

The successful creation of ICT communication infrastructures by volunteer contributions has been demonstrated by community networks [16]. In these types of networks, the contribution in terms of hardware is mainly wireless routers. However, in addition, volunteers also contribute technical knowledge that makes the network operational and used in production. Community networks are often used in areas where commercial Internet connectivity is not available, therefore, the reward for the contributors can simply be the service of having Internet connectivity. Cerdà-Alabern et al. conducted a detailed analysis of a compensation system to reward contributions to community networks [17]. There have also been proposals to use blockchain-based accounting of traffic for rewarding the contributors of wireless routers [18].

2.2. Trust in LoRaWAN and IoT Systems Supported by Blockchain

The topic of trust in IoT systems using blockchain is challenging, and there are several papers surveying the topic and other related topics [19,20,21,22]. In [19], Zubaydi et al. state that the major barrier to integrating blockchain with IoT is the reliability of IoT devices’ data, since the content of data can be changed or damaged before it arrives at the blockchain. Thus, the blockchain is unable to identify and verify the integrity of data. Kumar and Sharma, in [20], state that the potentially malicious input data from external sources to the blockchain, requested by smart contracts, is one of the key aspects of security goals to make a trusted IoT system. One potential solution for trust in the integrity of data is the use of smart contracts on blockchain to hold digests of large-scale IoT data.

An often used solution to provide trust in a decentralized application is by deploying services based on a permissioned blockchain [23,24,25,26]. Although this approach opens cases for the usage of blockchain in IoT services, it does not provide a change in paradigms. A permissioned blockchain limits the contribution of data to selected participants, using the same principle of current IoT services, in which only known authorities manage which users can participate in the network. This impedes the growth of the applications by third-party contributions.

In [27], Wang and Zhang propose the use of smart contracts of blockchain to maintain the integrity of large-scale IoT data. Our proposal is much more dynamic due to the use of environmental sensor data collected from the user community. We also need to incentivize this user community to collect data in quantity and quality. In addition, we offer the possibility of auditing data and devices.

The work of Zhao et al. [28] proposes a blockchain to build a privacy-preserving remote data integrity checking scheme. Compared to other approaches, their scheme supports dynamic auditing; it performs remote data integrity checks without needing a third-party auditor, eliminating data privacy leakage.

The work of Lücking et al. [29] used distributed ledger technologies to add attributes (e.g., accuracy, integrity, and reliability, among ten others), enhancing data quality verification of air pollution sensors. One of the motivations was the need for public authorities to have reliable pollution data, focusing on authenticity, availability, and tamper resistance. As a solution for providing these features, the work chose to integrate a permissioned distributed ledger based on Hyperledger Fabric in the system architecture, which restricts the participation to the verified consortium members but relieves tasks on identity management that applications using public permissionless blockchains may require. The system was implemented with real IoT devices that used LoRa communication. The IoT data are stored on the distributed ledger. Field tests were run and assessed whether the system was suitable to handle up to 500 transactions per second.

EdgeChain, proposed in [30], is a framework based on blockchain and smart contracts for delivering security benefits for IoT environments. Outsourcing security management to EdgeChain is argued by the low resource capacities of IoT devices, which impedes strong security solutions. Key architectural components are a permissioned blockchain, credit-based resource management, and a smart contract able to enforce an IoT device resource policy. An EdgeChain node is installed on an edge server. IoT devices install the software of EdgeChain to interact with an EdgeChain node. The IoT devices can request resources from the edge server, which is enabled by credit-based resource management over the smart contract. Thus, an EdgeChain node can monitor the IoT resource usage patterns, and smart contracts can enforce a resource policy if erroneous behavior is detected. The work has developed and evaluated a prototype. While using the framework has an overhead caused by the different operations with the blockchain, it assures that the IoT devices operate with their usual behavioral pattern, which creates trust.

In the work of Shahjalal et al. [31], the security of a LoRaWAN system for the Industrial Internet of Things (IIoT) is addressed. Specifically, the work proposes a low power, secure, and trusted data framework for LoRaWAN applications. A blockchain is used to implement distributed data management. For storing the encrypted sensor data, the Interplanetary file system (IPFS) is used. The metadata (IFPS CIDs) about the content stored in IPFS is written to the smart contract. The performance analysis was done with a small-scale deployment identified as the computational load on the backend server to perform data encryption. As this depends on the amount of data, higher-end processors may be chosen for the specific application case.

Advances in the deployment of blockchain for the healthcare industry’s IoT are proposed in [32]. The authors focus on mobile data offloading and propose deploying IPFS on top of mobile edge computing to increase system efficiency, particularly data retrieval rate. The decentralized smart contract associated with the IPFS layer enables authentication and data traceability in a hospital network without the need for an external authority. Although the results show an increase in efficiency in the data processing and access, the work points out a series of detected security vulnerabilities that present a challenge when deploying IoT technologies for sensitive data. The work of Nawaz et al. [33] proposes an edge-oriented service for improving data provider recognition by the transaction records in a blockchain. The work explores the use of blockchain features to enable data ownership as a base for data trading inside the network, among data producers and data consumers. The use of blockchain services at the fog and edge layer imposes many challenges in terms of security, as described in that work, while it is also a field of high opportunities mainly in terms of data sovereignty, reduction of carbon footprint, and decentralization.

The Dredas system [34] addresses the need for auditing IoT data stored in the cloud with regard to security and privacy properties. Instead of relying on a centralized trusted third-party auditor, an auditing smart contract in the Ethereum blockchain is used. For the evaluation, the system is implemented and deployed on a Rinkeby testnet. The cost analysis reveals a dependence between the increase in the gas cost and the computational time on the number of data blocks. Therefore, data blocks are sent in chunks of blocks in order to not exceed the gas limit of the transaction. In addition, it is proposed that instead of seeking the detection of all corrupt data blocks in the stored data, a probabilistic scheme is applied to detect a certain percentage of corrupted blocks. This way, the auditing operates only on a subset of the stored data, which reduces its cost.

3. LoRaTRUST Architecture

3.1. Environmental Monitoring Use Cases

In this section, we first analyze the stakeholders, their roles, and their use cases in an open participatory IoT environmental monitoring application, introducing thus the specific requirements for the LoRaTRUST platform.

The environmental monitoring application requires IoT devices that act as sensor nodes to acquire data. Thus, there is the role of a trusted provider for this hardware. This trusted provider delivers IoT devices that are admitted to be used within the system.

Sensor nodes have owners. In open IoT applications, an owner can be any participant that contributes a sensor node to the system. By placing operational nodes, a sensor owner produces IoT data and can be referred to as a data contributor or data owner.

The monitored data is used by data consumers to visualize the environmental situation and gain valuable knowledge from it, for external purposes.

An auditor is responsible for verifying the data that are obtained from data producers. The verification refers to making sure that the data are signed by a registered IoT device and that, in terms of data quality, the reported data are consistent with the device’s metadata. If the audit process detects any anomaly, it creates an alert. Otherwise, the data chunk is reported as correct and the data producer can be compensated accordingly. The auditor is a process that can run either as an automated service or can be manually requested from data contributors and data consumers. It is part of the backend of the LoRaTRUST platform.

We have identified the following use cases for these four actors (trusted provider, data producer, data consumer, auditor), summarized in Figure 3, for the LoRaTRUST platform:

• UC1.1 Add Device: The hardware provider adds an IoT device to the platform. Adding the device makes the device admitted. This device will be available for data contributors to be acquired and claimed.
• UC1.2 Claim Device: A data contributor, i.e., a participant that has acquired a device and is thus its owner, links their Ethereum address with the device’s Ethereum address. This enables compensation to the owner for the device’s data generation.
• UC2 Update Entity Profile: It allows any entity, e.g., a data provider or a data consumer, that participates in the system to create an account and provide profile information that can be accessed publicly. Such public information can support community building or facilitate sponsorship of specific environmental monitoring projects.
• UC3 Show Connectivity for Specific Device: A view with information about a particular IoT device is provided. It includes data visualization (telemetry view) generated with UC6.1.
• UC4 Show Devices Summary: A view of all IoT devices that belong to a data contributor is shown.
• UC5 Show Contributor Summary: A profile view of a data contributor and their activity is shown.
• UC6.1 Upload Data: IoT devices produce data that create a data flow in the system. These data consist mainly of the sensor measurements, but also device metadata, such as GPS coordinates, configuration details, and hardware information that helps to ensure the identity of the device and the correctness of the monitored data.
• UC6.2 Request Audit: A data contributor requests compensation for a data chunk. This implies that the data chunk has to be accessed by the auditor to validate it and grant the recognition of the contribution.
• UC6.3 Resolve Audit: An auditor resolves the request to report for a data chunk its data quality. Based on the results of the audit, the data chunk is flagged as audited and the compensation is granted to the data contributor.

In order to allow read and write operations of a smart contract of an Etherum-based blockchain, each participant that assumes a role of any of the four actors is required to have an Ethereum address.

3.2. Layered Architecture

The approach of the LoRaTRUST architecture to enhance trust in the IoT data of open monitoring applications is to integrate blockchain technology. Two key design decisions are made: (1) IoT data are split into high-volume data, which are stored off-chain, and proofs (hashes, digests), which are stored on-chain in smart contracts. This design keeps the data on the blockchain’s smart contract low without impeding the growth of data on the external storage service. (2) Ethereum addresses with their associated public and private key pairs are assigned to all actors, i.e., trusted provider, data producer, data consumer, and auditor, of the system. This allows all participants to have a unique identity in the blockchain-hosted smart contract.

Figure 4 displays the four layers of the LoRaTRUST architecture, which consists of the L1 Data Generation Layer, L2 Data Aggregation Layer, L3 Data Services Components Layer, and L4 Frontend Services Layer.

The Data Generation Layer (Layer 1) acquires sensor data and sends the data in a LoRa packet to the L2 Data Aggregation Layer. It contains several components: the Data Retrieval (C1.1), referring to the board obtaining data from the sensor, Key Management (C1.2), the software that generates the node’s private key, Data Signer (C1.3), referring to the component that enables the node to sign the sensor data, Data Encrypter (C1.4), an architectural component to address application scenarios with confidential data, and Data Sender (C1.5), the software that sends the signed data as a LoRa packet.

The Data Aggregation Layer (Layer 2) receives IoT sensor data and aggregates them to be sent northbound to the L3 layer hosted on the Internet. The layer contains the Data Router (C2.1), which sends the data over an http to the backend of Layer 3. The ACL Policy (C2.2) component addresses the possibility to setup network-level security at the gateway’s network interfaces. Since the data transmission between layers 1 and 2 uses LoRa communication technology, which may face packet losses, additional protocols are needed if the delivery of data from layers 1 and 2 should be guaranteed.

The Data Services Components Layer (Figure 5) includes L3.1 backend services, such as HTTP server (C3.3.1), Data Persistence (C3.1.2), Data Anchoring (C3.1.3), Backend API (C3.1.4), Data Replication (C3.1.5), Message Broker (C3.1.6), and Blockchain Oracle and Data Scoring (C3.1.7) components. These components are for the provision of data storage services and handle data redundancy, blockchain anchoring pattern, sensor data verification, and validating accounting information. The oracle is introduced for the smart contract to be able to obtain external information to accept write operations. The oracle is related to the auditor process introduced previously, where the successful audits of data chunks produce writes of the digests of reports and the contribution accounting in the on-chain storage.

The L3.2 blockchain services provide a blockchain-based distributed ledger technology for the persistence of core metadata related to the system, with a smart contract (C3.2.2) that deals with device identities, audits, and contribution accounting. It holds the blockchain address of each participant, with operations managed by a crypto wallet (C3.2.3).

The L4 Application Services Components include Authentication (C4.1), Data Access (C4.2), Data Verifier (C4.3), and Reporting (C4.4) components for controlling access to non-public data, providing a graphical view of the data to data consumers, allowing data consumers to manually verify the trustworthiness of the data by triggering the audit process, and allowing access to documents generated by previously run audits, respectively. Component C4.3, specifically, is the frontend function for a data consumer to manually run an audit process or access results of previously run audits.

3.3. Data Model

LoRaTRUST is conceived as an open environmental monitoring application that encompasses different types of data. The first type is the IoT data that come from the sensor nodes’ measurements. The second type refers to the contribution data that indicate from which device the IoT data originated. The third type is the device description to identify any node in the monitoring system.

The data flow in the system starts at the sensor node and moves to the backend, hosted on the Internet. Data are stored in specific components of each layer to facilitate communication with the upper layers. In the IoT layers 1 and 2, the C1.5 Data Sender, which is part of the L1 Data Generation layer, has configuration variables that hold the LoRa address of the C2.1 Data Router. The C2.1 Data Router, which is part of the L2 Data Aggregation layer, contains configuration variables that hold the URL of the C3.1.1 HTTP server component and the LoRa addresses of the C1.5 Data Sender components.

Within the Internet-hosted layer 3, the L3.1 Backend service has a distributed database that stores the records of the received measurements and metadata. The L3.2 Blockchain service corresponds to a smart contract hosted on the blockchain, containing proofs (hashes) for data to enable verification that data are unaltered after the previous validation of authenticated origin, as well as containing the Ethereum addresses of the actors participating in the system to enable the verification of the identity of data producers. The L3.1 and L3.2 components are related in that L3.1 contains the data files, while L3.2 contains the proofs for these data, representing thus the implementation of the blockchain anchor pattern.

4. Prototype Implementation

4.1. Prototype

LoRaTRUST has been developed as a prototype that implements the architecture described in Section 3.

Layer 1 Data Generation and Layer 2 Data Aggregation: For prototyping the IoT layer, we utilized real IoT devices. The hardware is compatible with the ESP32 microcontroller and with the SX1276 LoRa transceiver. For the prototype deployment, different types of boards, including the TTGO T-Beam embedded system and the Nayad (https://gitlab.com/hacking-ecology/nayad/, accessed on 1 March 2023) multisensor board (Figure 6), were used. The Nayad board is equipped with an integrated cryptographic coprocessor that provides advanced and secure key management for LoRaTRUST.

The IoT device is flashed with the LoRaTRUST firmware (https://codeberg.org/LoRaTRUST/LoRaTRUST-firmware, accessed on 1 March 2023) and can operate as a gateway, a sensor node, or both, depending on Internet availability. Sensor nodes are arranged in a mesh network topology, and gateways are connected to the Internet. The firmware uses LoRaMesher technology to facilitate the communication between sensor and gateway nodes [35]. As sensor data, we have used the GPS locations of the devices. When LoRaTRUST is used for real IoT monitoring applications, the specific environmental sensors required by the application would be used.

Layer 3 Data Services: This layer is hosted on the Internet and consists of the backend, blockchain, and web UI services. In our prototype, all these services are deployed on an Ubuntu virtual machine in the Microsoft Azure cloud platform. The backend service uses Node.js to develop a RESTful API that facilitates communication between the IoT layer and the blockchain service. The blockchain service, developed using Solidity, implements the blockchain anchor pattern and is deployed on an Ethereum testnet materialized by a publicly accessible Ganache instance. The Web UI service is developed using React.js and enables the user to interact with the data stored in the database and the blockchain.

The smart contract contains data structures that register the Ethereum addresses of all allowed IoT devices in the system, along with the owners’ relation to devices and owner addresses (Figure 7). The complete implementation of the smart contract is available in an open Git repository (https://codeberg.org/LoRaTRUST/loratrust-truffle, accessed on 1 March 2023).

The Audit and NetworkDevice structs allow having 0..N audits per device. The audits verify device sensor data and account for the contribution of the data owner, leveraging the patterns of oracle and data anchoring described in the previous section.

Measurement, Event, and Metadata are structured JSON objects generated by the sensor nodes at the Data Generation layer. These persisted data are stored outside the blockchain in a time-series database. The most frequent message type sent by a sensor node is the measurement message. Examples of measurement types are water temperature, water pH, electric conductivity, air temperature, air humidity, soil moisture, or soil pH (Figure 8).

The event message type is similar to the measurement message type but is triggered and sent by the sensor in the context of an alert or a warning configured in the device’s firmware. Examples of events are low battery level warnings, successful calibration processes, etc., (Figure 9).

The metadata message type, as shown in Figure 10, contains information to facilitate device identification and to know the current device status.

Layer 4 Frontend Services: The main web page for data consumers of the LoRaTRUST system is displayed in Figure 11. It provides an overview of the IoT data captured, the number of devices, and verified and non-verified data. From there, data consumers can navigate to a specific page that shows details about the different hosted IoT monitoring projects (Figure 12). After selecting a particular project, users can obtain more detailed information. The purpose of this page is to enable data consumers to find data about specific projects.

4.2. Analysis of Trust-Enhancing Measures

We analyze the trust-enhancing measures at the different architectural layers.

Layer 1 Data Generation: Cryptographic functions are utilized to achieve trust in the measured IoT data and device identification. The ECDSA signature authenticates the sensor nodes that generated the data, allowing also to determine its Ethereum address. The Etherum address represents a node’s unique identity in the system. The Ethereum addresses of all sensor devices are known to the system through the smart contract’s ecrecover solidity function. Only trusted providers can add new sensor nodes to the system. The digital signatures of the data by the sensor devices ensure data integrity and confirm the identity of the device that sent the data. Metadata messages containing information such as GPS coordinates and MAC addresses are transmitted along the sensor readings to detect outliers and anomalies. The integration of metadata information when performing an audit process over obtained sensor data provides evidence about data quality and, hence, trust in these data.

Layer 2 Data Aggregation: The gateways in layer 2 receive signed data messages from the sensor nodes and forward them to the backend service on the Internet. The gateway, which also signs the data received from IoT sensor nodes, also transmits the metadata information received for the backend to have an updated view of each sensor node. The purpose of the gateway node signing the message is to be able to account the gateway provision as a contribution.

L3.1 Backend Services: The backend consists of a stateless web application with a persistent data service. Multiple instances of this component could exist, hosted privately or publicly. The prototype demonstration hosts a publicly accessible instance on the Internet. The backend reads smart contract variables to verify signatures from the sensor and gateway nodes. Only data from added IoT devices (UC 1.1) and registered/claimed IoT devices (UC1.2) are accepted by the backend service. The persistent data service stores raw IoT data and contribution data, with the proofs of these data stored in the variables of the smart contract.

L3.2 Blockchain Service Components: The blockchain smart contract contains proofs for the IoT data stored in the persistent data service. Proofs consist of hashes and the data’s location in the storage system. This allows detecting changes in the stored IoT data. Verification of IoT data is enabled by the backend service’s operations with the smart contract. The blockchain smart contract also accounts for users’ contributions, including hardware provisions, operational expenses, and data generation. The oracle pattern is applied to account for IoT data production. For this, the backend’s audit process is run, which, by writing to smart contract the results related to the nodes’ contributions, enables the smart contract to account for them. The association of devices and their owners are stored in the smart contract.

L4 Application Services Components: This component relies on the mechanisms for trust implemented on the lower architectural layers to provide trust to the data consumer. It allows IoT data to be consulted with assurance about the sensor data authenticity and to be untampered along the data flow from IoT sensor nodes to the persistent data service. The contribution information about data and hardware providers and the owner’s own devices can be similarly verified.

4.3. Prevention of Malicious Behavior

This section assesses how LoRaTRUST prevents the manipulation of IoT data values and accounting contributions, for ensuring trust in monitored data and correct accounting for being able to provide the corresponding rewards to the contributors.

4.3.1. IoT Data Manipulation

Manipulating measured IoT data or injecting invalid data into the system can lead to incorrect interpretations of data collected by the LoRaTRUST system. LoRaTRUST implements several mechanisms to prevent the manipulation of IoT data, making it difficult for anyone other than experts to manipulate data, including:

• Each participating IoT node has its public key registered in the smart contract. Therefore, external nodes that are not registered in the smart contract are prevented from storing any data that the audit process accepts.
• The private key stored on the microcontroller is not easily readable for non-experts, which reduces the possibility of being copied.
• Secure Boot ensures that only authorized firmware can be used to change the code of a microcontroller, making unauthorized firmware updates invalid.
• IoT sensor nodes periodically send metadata to the LoRaTRUST system. Thus, the backend can detect any changes in the node.
• GPS data and timestamps are sent, which can help detect manipulation or malfunctioning by comparing a node’s measurements with those of nearby nodes.

4.3.2. Data Veracity

Sensor measurements themselves may not reflect the true values of the environment. False values can come from the manipulation of the environmental conditions by a malicious user, such that a correctly working sensor will measure values that do not represent the true environment. False values may also be produced if the sensor is not calibrated or has a malfunction. If only values from a single sensor are considered, these cases are difficult to be detected and be distinguished from each other. Differently, if more nearly independent sensors are available, outliers of a single sensor can be detected and assessed, such as described in [36], which may also help for the calibration of sensors.

4.3.3. Accounting Contribution Manipulation

Contributors may try to manipulate the accounting of contributions to increase their rewards. LoRaTRUST prevents this in several ways:

• For hardware contributions, device owners can only register devices previously added by trusted hardware providers, and each device key is registered in the smart contract, preventing non-existent devices from being claimed.
• For data contributions, instead of accounting for the number of measurements, the approach of LoRaTRUST is to assess the quality of the measurements, for which we have started to develop quality indices. The quality value of a data contribution is communicated to the LoRaTRUST smart contract through the auditor.

While participation in LoRaTRUST accounts for being able to offer rewards, these rewards are not designed for making huge profits or speculation. Indeed, municipalities that benefit from a LoRaTRUST monitoring system may offer non-monetary rewards, such as transportation vouchers or similar. Although some users may attempt to cheat by manipulating their contributions with a higher effort, given the non-monetary nature of the rewards, many other users are expected to be incentivized to participate in the system, even for small rewards, making cheating less likely.

5. Discussion

The prototype development has led to the demonstration in terms of a public deployment of a proof-of-concept implementation of the LoRaTRUST system. The design assigns Ethereum addresses to the owners of the IoT devices (sensor nodes and gateways), and ECDSA private–public key pairs are used for signing and authenticating messages from these devices. Since the application establishes a relationship between the devices and owners, the smart contract’s registered operations can be attributed to the respective owner accounts. This approach quantifies the devices’ actions, accounting thus for each owner’s contribution.

While the LoRaTRUST design has chosen the backend service to interact with the smart contract, alternative approaches have been proposed in the literature where the IoT nodes directly operate with the blockchain’s smart contract [37,38]. However, the 256B maximum size of a LoRa packet limits what can be contained in such a transaction. Another issue is how to separate the messages of the IoT device into the two storage destinations, off-chain and on-chain, when the high volume IoT is stored in a database and the proofs of a data chunk are stored in the blockchain. The backend service used in LoRaTRUST, described in Section 3.2, generates content for both on-chain and off-chain storage from the different message types received from an IoT device.

The current implementation of LoRaTRUST lacks a functionally rich search capacity. In our implementation, the search is limited to querying trusted data from the database. However, these data, which the data consumer can obtain from the database, are not real-time data. Since proofs are computed for chunks of IoT data, there is a delay, configurable in terms of the chunk size, from the data value obtained at the sensor node until its final storage on the database. An enriched search function for querying directly the IoT sensor nodes could open new application cases to LoRaTRUST, such as applications that require near real-time information for short response times. The LoRaMesher technology [35] used in LoRaTRUST principally can route queries from the backend to IoT devices, but such a use case has not yet been enabled in the current implementation.

The LoRaTRUST application target is open participatory IoT applications for enhancing trust. While this openness allows the application to be joined by all data contributors who own an Ethereum account, only previously registered devices can be used for data contribution. Initially, the smart contract must contain a set of trusted hardware providers that are the only ones allowed to register IoT devices that data contributors can acquire. This approach has the effect to ensure that any data that are provided by the application have come from a known device, but limits the scope of admitted hardware to previously registered devices.

The current LoRaTRUST design has developed a generic accounting capacity to compensate data producers. The trading of IoT data is a possible extension for which blockchain-based solutions have already been proposed, e.g., [33]. Such a data market for trading could be developed as an additional component interfacing with the trusted data storage. Different policies for sharing data could be enabled, for instance, selective sharing with data consumers for obtaining compensation or controlled sharing to maintain the confidentiality of the data. Figure 13 illustrates such a data market for trading as an additional component interfacing with the trusted data of LoRaTRUST.

6. Conclusions

This paper presented LoRaTRUST, a blockchain-based accounting and data trust system for open participatory IoT monitoring applications. Citizens that acquire registered IoT devices from trusted providers can contribute with hardware and IoT data to such applications and perform environmental monitoring. The trust-enhanced monitoring application can benefit decision makers to make evidenced decisions upon the trusted IoT data. Then, the proven usefulness of these data can raise the willingness of data consumers to compensate contributors. Finally, the blockchain-based trusted accounting creates incentives for participation and contributions, thus making open participatory IoT monitoring applications valuable and sustainable.

The architecture and a proof-of-concept implementation of LoRaTRUST were developed and demonstrated, with a smart contract used to store proofs about data provision and information about the IoT devices used for data collection. An audit process was introduced for validating the received IoT data chunks and assessing the contributions of the participants, therefore providing to the data consumer trust in the data delivered by the application and to the participants an accounting of their contributions. A key design decision was to assign Ethereum addresses with their associated public and private key pairs for all actors, thus allowing the contributions to be correctly attributed and accounted for a later reward.

Currently, the LoRaTRUST system provides trust in the IoT data based on verifiable data integrity and authentication of origin, as well as by assessing the IoT data quality with the sensor node’s metadata information. However, for the system to be useful in real cases, the concrete trust requirements from the specific IoT monitoring application of the data consumer should be applied. For example, many cities worldwide will soon face certification obligations from their legislative bodies to ensure air quality for their citizens. This is an opportunity for LoRaTRUST to integrate in future developments these requirements that customize LoRaTRUST and hence demonstrate the system as a service for trusted data in such important application cases. Given the availability of an operational prototype of LoRaTRUST, we will also seek in future work to perform practical evaluations of LoRaTRUST with pilot applications. For this purpose, we have already singled out a large environmental monitoring project to be conducted at the Mediterranean cost, for which we aim to apply the LoRaTRUST system.