# **Security and Privacy in Blockchains and the IoT**

## Edited by Christoph Stach Printed Edition of the Special Issue Published in *Future Internet*

www.mdpi.com/journal/futureinternet

## **Security and Privacy in Blockchains and the IoT**

## **Security and Privacy in Blockchains and the IoT**

Editor **Christoph Stach**

MDPI • Basel • Beijing • Wuhan • Barcelona • Belgrade • Manchester • Tokyo • Cluj • Tianjin

*Editor* Christoph Stach University of Stuttgart Germany

*Editorial Office* MDPI St. Alban-Anlage 66 4052 Basel, Switzerland

This is a reprint of articles from the Special Issue published online in the open access journal *Future Internet* (ISSN 1999-5903) (available at: https://www.mdpi.com/journal/futureinternet/ special issues/SP BI).

For citation purposes, cite each article independently as indicated on the article page online and as indicated below:

LastName, A.A.; LastName, B.B.; LastName, C.C. Article Title. *Journal Name* **Year**, *Volume Number*, Page Range.

**ISBN 978-3-0365-6251-3 (Hbk) ISBN 978-3-0365-6252-0 (PDF)**

Cover image courtesy of Pexels

© 2023 by the authors. Articles in this book are Open Access and distributed under the Creative Commons Attribution (CC BY) license, which allows users to download, copy and build upon published articles, as long as the author and publisher are properly credited, which ensures maximum dissemination and a wider impact of our publications.

The book as a whole is distributed by MDPI under the terms and conditions of the Creative Commons license CC BY-NC-ND.

## **Contents**


## **About the Editor**

#### **Christoph Stach**

Dr. rer. nat. Christoph Stach is a postdoctoral researcher at the Applications of Parallel and Distributed Systems department of the University of Stuttgart. He completed his studies in computer science at the University of Stuttgart in 2009. In 2017, he received his PhD in computer science from the University of Stuttgart for his research in the area of information security and data privacy in mobile applications. Following his successful doctorate, he was appointed Academic Councilor at the Institute for Parallel and Distributed Systems of the University of Stuttgart. From June 2020 to September 2021, he held the deputy professorship in Data Engineering at the University of Stuttgart. At present, he is head of the working area of Information Systems and Applications at the Applications of Parallel and Distributed Systems department of the University of Stuttgart. His current research focuses on the concepts and tools required to enable trustworthy and demand-oriented data provisioning for users, such as data scientists and data analysts. To this end, his research addresses research questions regarding data acquisition, data management, data security, and data protection. He has published more than 60 peer-reviewed papers about his research and presented the results at international conferences. For his work, he has received four awards. He also shares his knowledge and experience by giving lectures, such as Introduction to Data Science and Applied Data Science using Python, as well as holding seminars on these topics.

## **Preface to "Security and Privacy in Blockchains and the IoT"**

Smart devices, i.e., everyday objects equipped with comprehensive sensor technology, are becoming increasingly popular. Due to the ubiquity of such devices in our daily lives, data on all kinds of events can continuously be captured and analyzed. As the Internet of Things (IoT) interconnects smart devices, data from a wide range of domains can be linked. Such enriched datasets are the driver for a variety of innovative smart services, e.g., in the eHealth or Industry 4.0 domain. As a result, these data have a high economic value and require special security considerations. Security, in this context, refers to two different facets: On the one hand, the integrity of the data must be protected against illegal manipulation and the availability of the data has to be assured. Blockchain technologies are widely used for this purpose, as they enable the immutable and tamper-resistant storage and sharing of data. On the other hand, applicable data protection laws, such as the EU General Data Protection Regulation (GDPR), set high standards for data processing when it comes to personal data. This is important because a lot of sensitive information can be derived from such data.

To this end, research approaches and insights from practice are discussed in this book, addressing security and privacy issues in the context of blockchain technologies and the IoT. The presented work covers a broad spectrum, ranging from approaches strengthening trust in networks such as the IoT to approaches improving the effectiveness and efficiency of blockchain technologies in terms of query capacities and consensus procedures, as well as approaches enabling the privacy-compliant sharing of IoT data using blockchain technologies. The book is capped off by literature reviews that shed light on what privacy-critical information can be derived from encrypted network traffic flow segments and how blockchain technologies can be leveraged in the ambient assisted-living domain.

As data security and privacy concerns increasingly impact our lives, and blockchain technologies as well as the IoT are prevalent in virtually all domains, the subject matter in this book is, therefore, aimed at both the general and expert audience. The provided overview of the state-of-the-art and state of research addresses developers and researchers as well as end-users. Therefore, this book is recommended to everyone who wants to gain the latest insights and learn about new findings on security and privacy in blockchains and the IoT.

This book has only been made possible due to the authors who have contributed interesting papers about their excellent research work. The editor, therefore, thanks all involved authors. Moreover, he expresses his appreciation to all the reviewers, who were not only essential in selecting the papers for this book but whose valuable comments also ensured that the quality of the selected papers was improved even further. A final word of gratitude goes to the MDPI editorial team, who invested a lot of time and effort in contacting the authors and reviewers and made the publication of this book possible in the first place.

> **Christoph Stach** *Editor*

### *Editorial* **Special Issue on Security and Privacy in Blockchains and the IoT**

**Christoph Stach**

Institute for Parallel and Distributed Systems, University of Stuttgart, Universitätsstraße 38, 70569 Stuttgart, Germany; christoph.stach@ipvs.uni-stuttgart.de

The increasing digitalization in all areas of life is leading step-by-step to a data-driven society. From an information technology perspective, this process is particularly promoted by the Internet of Things (IoT). Nowadays, a variety of sensors can be embedded in virtually any everyday object, enabling users to continuously quantify a wide range of aspects of life. For instance, a smartwatch can use GPS technologies to determine the current location of its user, an accelerometer and gyroscope to recognize the user's activity, and a microphone to capture and interpret voice messages and spoken instructions of its user. Even special use sensors are installed in those IoT devices, such as a heart rate sensor or sensors for recording insulin levels, which can be used to capture and monitor health data. Additionally, such IoT devices have the ability to communicate with each other and exchange the data they gather. In this way, large amounts of data can be collected. Comprehensive processing and analysis of these data (e.g., in a powerful cloud backend) makes it possible to draw conclusions about the context in which an IoT device is used and generate knowledge about the data subjects. This gained knowledge represents the foundation of any smart service, not only in the private sector but also in the public and industrial sectors, such as in the smart home, eHealth, and Industry 4.0 domains.

This renders data as one of the most valuable assets in the information age. Therefore, it is important to manage data securely. Blockchain technologies are often applied to this end, as they ensure the immutability and tamper-resistance of data when they have to be exchanged between multiple parties that do not entirely trust each other. In additions to these information security measures, such highly sensitive data also pose great challenges with respect to data privacy. Applicable data protection laws, such as the EU's General Data Protection Regulation (GDPR), therefore demand the development and application of technical mechanisms that ensure the protection of any natural person when processing their data. In order to ensure that such protective measures are effective, however, they must be tailored to the IoT and blockchain technologies. In this regard, it must be investigated, e.g., how lightweight and privacy-preserving authentication in the IoT is possible; which trust-building approaches regarding the genuineness and validity of IoT data can be applied; and how blockchain systems can efficiently manage big data.

These and related research questions regarding security and privacy in blockchains and the IoT are addressed by six research articles and two literature reviews in this Special Issue. In the following, these eight papers are briefly outlined.

**Articles.** Two of the research articles address the question of how security and trust in IoT environments and IoT applications can be increased. Alzahrani and Fotiou [1] address how one-to-many communication—or group communication—can be made more secure in software-defined networking (SDN). SDN enables the self-organization of IoT groups by the IoT devices, which reflects the original IoT vision of a network of autonomous things. However, this poses the risk that such an SDN is flooded with fake messages and instructions from malicious things. To counteract this, the authors present an approach in which only authorized endpoints can send instructions to the network. Linked data signatures are used to prove the validity of the instructions. By means of linked data proofs, the presented approach supports zero-knowledge proofs to reliably secure IoT group communications against malicious things. Wei et al. [2] present a different approach

**Citation:** Stach, C. Special Issue on Security and Privacy in Blockchains and the IoT. *Future Internet* **2022**, *14*, 317. https://doi.org/10.3390/ fi14110317

Received: 27 October 2022 Accepted: 28 October 2022 Published: 1 November 2022

**Publisher's Note:** MDPI stays neutral with regard to jurisdictional claims in published maps and institutional affiliations.

**Copyright:** © 2022 by the author. Licensee MDPI, Basel, Switzerland. This article is an open access article distributed under the terms and conditions of the Creative Commons Attribution (CC BY) license (https:// creativecommons.org/licenses/by/ 4.0/).

to increasing trust in IoT applications. They look at the Social Internet of Things (SIoT), in which smart devices autonomously establish social connections with each other. In this way, whenever necessary, things can become service requesters or service providers on their own, without the need for any human intervention. It is obvious that—similar to real-world services—trust in the service provider is required, e.g., whether it is able to provide the advertised services. While there are approaches that can adequately model this kind of trust in SIoT, these state-of-the-art approaches completely ignore the fact that a service provider has to trust a service requester as well. This work therefore focuses on modeling bidirectional trust in SIoT. This kind of modeling introduces additional complexity due to the fact that trust is context-dependent and can vary depending on the given situation. Based on their bidirectional trust model, the authors discuss a trust-based service delegation method in SIoT, which considers not only the level of trust between a service requester and a service provider but also the utility of the offered service.

Two of the research articles are dedicated to blockchain technologies. While blockchain systems enable secure data management in terms of immutability and tamper resistance, they typically lack comprehensive query capabilities. Przytarski et al. [3] therefore review the current state of query processing in blockchain systems and the future challenges in this research area. For this purpose, they initially investigate in which application domains blockchain technologies are used as part of big data management systems. Based on this, they determine which types of data and which data models are primarily used in this context. They then study the query capabilities of today's blockchain systems and discuss to what extent they meet the requirements of the use cases from the application domains. Furthermore, they give an outlook on how the internal data structures as well as the block structures of a blockchain system have to be adapted in order to efficiently support complex queries, such as history queries over time series data. Qu et al. [4] address another inherent problem in blockchain systems. As the blockchain uses a distributed ledger as its underlying infrastructure, i.e., a replicated, shared, and synchronized data store whose instances are managed by multiple parties, all involved parties have to agree on what data should be added to the blockchain. To synchronize changes, consensus methods such as proof of work (PoW) are used. A major disadvantage of PoW, however, is that it is very computation-intensive and therefore favors parties that have access to powerful computing capacities. In order to provide more fairness in the case of heterogeneous parties, e.g., in IoT environments, the authors interpose edge devices that monitor each computing node participating in PoW. This monitoring is based on a digital twin approach that simulates the normally expected behavior of each computing node. As a result, misbehavior by dishonest participants can be detected, e.g., computing nodes that use extra computing power to outperform their competitors. By means of a proof-of-concept implementation, the authors demonstrate not only the feasibility but also the efficiency of their approach.

The remaining two research articles focus on how blockchain technologies can be applied in the IoT to ensure privacy aspects, namely, access control and privacy-aware data sharing. While IoT applications typically rely on a central data backend that is responsible for the management of the collected data, such an approach poses a risk from a security perspective. Since a single entity operates this backend and thus has full control over the data, tampering is easily possible. Blockchain-based solutions, which manage the data in a distributed manner and are jointly operated by multiple parties, overcome this problem. However, they cause major privacy concerns, as an access policy for confidential data must be reliably applied to all data nodes involved. Khanal et al. [5] therefore introduce a two-pronged approach by which access to sensitive IoT data can only take place with the consent of the data subject. This approach uses a combination of a secure hash function and a key derivation function to encrypt the data. The data in the blockchain can only be decrypted if the data subject has given their consent. With their approach, the authors not only improve reliability but also reduce the computation time compared to state-of-the-art approaches. Gangwani et al. [6] also present an approach with which confidential IoT data can be trustworthily shared among multiple parties using

distributed ledger technology. However, their approach relies on IOTA, a distributedledger-based communication protocol specifically tailored to the requirements of the IoT. Unlike blockchain-based approaches, IOTA is highly scalable, as restrictions on block size or mining costs are not an issue. As a result, it can also be used to share large amounts of sensor data at a rapid rate. The masked authenticated messaging (MAM) extension for IOTA is used to ensure confidentiality. With MAM, data streams can be sent encrypted as transactions with zero additional cost. Furthermore, MAM provides data subjects with fine-grained access control, allowing them to revoke access to their data at any given time. The authors demonstrate the high potential of IOTA and MAM when dealing with sensitive IoT data by means of an environmental monitoring application.

**Reviews.** Two literature reviews on in-app activity recognition based on encrypted traffic flow segments and on application areas for blockchain technologies in ambient assisted living wrap up this Special Issue. As the adoption of IoT technologies across all areas of life becomes more and more prevalent, not only the extent of data collection but also the network traffic increases. This is due to the fact that IoT applications do not carry out data processing on the IoT devices themselves, but in a powerful backend. As a result, these applications have to send their data to the backend on a continuous basis. Typically, this data stream is encrypted to ensure that third parties do not gain insight into the transferred payload data. However, even encrypted traffic flow segments still allow conclusions to be drawn about in-app activities, which compromises the privacy of the user. In their review, Pathmaperuma et al. [7] therefore investigate which types of traffic classification exist in the literature. Essentially, there are statistical methods and approaches based on neural networks. In addition to this literature review, the authors also propose their own approach to user activity detection based on in-app data. To this end, they apply an image-based method. Instead of analyzing the network traffic itself, they transform the detected patterns into images, where each pixel stands for features and corresponding feature values of the traffic data. For eight popular mobile applications (e.g., Facebook, Instagram, and WhatsApp), the authors record the network traffic generated by typical in-app activities (e.g., post an image, like an image, and send a short text message). These samples are cleansed, pre-processed, and transformed, resulting in a comprehensive database with characteristic images for each of the in-app activities. A convolutional neural network (CNN) is trained with this image database. The CNN is able to classify activities based on their network traffics with an accuracy of 88 % to 92 %.

One sector that benefits significantly from the IoT and the accompanying comprehensive data collection is the healthcare sector. In particular, recurring routine medical checkups, for instance, in the case of chronic diseases, can be carried out remotely, thus relieving both patients and physicians. As a result of the COVID-19 pandemic, there are increased demands to provide assisted care services remotely. Ambient assisted living (AAL) uses IoT technologies to provide non-intrusive support for the daily lives of elderly or disabled people without the need for a caregiver on site. Since the monitoring required for this purpose collects a large amount of highly personal data, there are justified security and privacy concerns regarding data management. The strategic use of blockchain technologies has the potential to alleviate these concerns. Florea et al. [8] therefore conduct a systematic literature review which aims to identify fields of application for blockchain technologies in the AAL and to highlight advantages and open issues in this context. For this purpose, they selected a literature corpus of 472 scientific papers published in high-quality conferences and journals. In a systematic approach following the PRISM process flow, they condensed this overall corpus to the most relevant papers. Based on these 87 core papers, the authors identify three AAL use cases for which the use of blockchain technologies generates a significant added value. These use cases, which are also further detailed in the review, are IoT-based monitoring and intervention, decentralized patient data management, and AAL system security and privacy. Despite the undeniable benefits that blockchain technologies can provide in these areas, the authors also identify some obstacles that need to be addressed in further research. For instance, there is a need to reduce the transactional and

storage costs inherent in managing large amounts of data in blockchain systems, to facilitate the integration of blockchain systems into legacy infrastructures prevalent in many AAL environments, and to ensure the privacy of data managed by a blockchain system.

The eight excellent papers in this Special Issue provide a good overview of security and privacy issues in blockchain systems and the IoT. The research articles present practical solutions to some of these issues. While the literature reviews reveal that there are still several security and privacy issues that need to be addressed in the future, they also show that the use of blockchain technologies and the IoT is beneficial to the daily lives of all of us. It is therefore important to address the questions raised in this Special Issue in the future, in order to make the usage of IoT technologies and blockchain systems as secure and privacy aware as possible.

I would like to thank all the authors for submitting their interesting and informative manuscripts to this Special Issue. I would also like to acknowledge all the reviewers whose thorough and substantial reviews further improved the quality of the manuscripts and without whom this Special Issue would not have been possible. Last but not least, I would like to thank the MDPI editorial team whose support has been instrumental in my work on this Special Issue.

**Funding:** This research received no external funding.

**Conflicts of Interest:** The author declares no conflict of interest.

#### **References**


### *Article* **Securing SDN-Based IoT Group Communication**

**Bander Alzahrani <sup>1</sup> and Nikos Fotiou 2,\***


**Abstract:** IoT group communication allows users to control multiple IoT devices simultaneously. A convenient method for implementing this communication paradigm is by leveraging softwaredefined networking (SDN) and allowing IoT endpoints to "advertise" the resources that can be accessed through group communication. In this paper, we propose a solution for securing this process by preventing IoT endpoints from advertising "fake" resources. We consider group communication using the constrained application protocol (CoAP), and we leverage Web of Things (WoT) Thing Description (TD) to enable resources' advertisement. In order to achieve our goal, we are using linked-data proofs. Additionally, we evaluate the application of zero-knowledge proofs (ZKPs) for hiding certain properties of a WoT-TD file.

**Keywords:** crowd management; software-defined networking; linked-data signatures; Web of Things; zero-knowledge proofs

#### **1. Introduction**

The Internet of Things (IoT) considers "unconventional" communication paradigms such as "publish–subscribe" or "one-to-many" communication; in this paper, we focus on the latter paradigm, which is usually referred to as group communication. Although this paradigm is not typical in mainstream communication systems, we postulate that this is not the case for the IoT. We consider as a use case the crowd monitoring system presented in [1]. This system includes gas and ultrasonic sensors, UAVs equipped with cameras and LiDARs, as well as CCTV systems (see also Figure 1). In this system, tasks such as "collect all measurements in area X" or "turn on all cameras in area Z" are not uncommon scenarios, and the reasonable approach for implementing them is using group communication.

Group communication using the constrained application protocol (CoAP) [2] is a promising direction, which is impeded by the lack of adoption of IP Multicast, however. On the other hand, interconnecting IoT devices over software-defined networking (SDN)—such as in the architecture presented in [1]—enables alternative approaches for implementing group communication that removes the need for IP multicast and enables "self-organizing" IoT groups, where IoT endpoints can "advertise" the CoAP URIs of their resources, and groups can be automatically created based on these advertisements. Therefore, it is obvious that this advertisement process must be protected; otherwise, malicious entities may "pollute" the network with "fake" advertisements, affecting this way the group formation process.

In this paper, we provide a solution to this problem by allowing only authorized endpoints to perform advertisements. From a high-level perspective, we consider that each endpoint "represents" its available resource using a JSON-encoded file and by following the W3C Web of Things, Thing Description (WoT-TD) specifications [3]. This WoT-TD file is signed by a trusted service provider, and it is included in the advertisements, together with proof of ownership. The recipients of such an advertisement can then easily verify its validity. In this paper, we make the following contributions:

**Citation:** Alzahrani, B.; Fotiou, N. Securing SDN-Based IoT Group Communication. *Future Internet* **2021**, *13*, 207. https://doi.org/10.3390/ fi13080207

Academic Editor: Christoph Stach

Received: 9 July 2021 Accepted: 3 August 2021 Published: 9 August 2021

**Publisher's Note:** MDPI stays neutral with regard to jurisdictional claims in published maps and institutional affiliations.

**Copyright:** © 2021 by the authors. Licensee MDPI, Basel, Switzerland. This article is an open access article distributed under the terms and conditions of the Creative Commons Attribution (CC BY) license (https:// creativecommons.org/licenses/by/ 4.0/).

**Figure 1.** An overview of the entities of the proposed solution.


The remainder of this paper is organized as follows: In Section 2, we introduce the technologies used as building blocks of our system. In Section 3, we detail the design of our solution, and in Section 4, we present its implementation and evaluation. We discuss related work in this area in Section 5, and we conclude our paper in Section 6.

#### **2. Background**

#### *2.1. SDN and Bloom Filter-Based Forwarding*

Software-defined networking (SDN) [4] is a technology that allows a centralized entity, known as the "network controller" (or simply controller) to control programmable switches. SDN switches forward packets based on rules defined by the controller. In particular, in order for a switch to determine how to handle an incoming packet, it either queries the controller or uses a set of rules stored in the switch using a protocol such as OpenFlow [5].

SDN can be used for implementing Bloom filter [6]-based packet forwarding [7]. This type of forwarding enables multicast communication in an efficient, fast, and stateless way. From a high-level perspective, the solution in [7] assumes that each outgoing interface of an SDN switch is identified by a bitstring identifier; then, it uses a Bloom filter to encode the identifiers of all interfaces through which a packet should be forwarded; finally, it stores this forwarding identifier in the IPv6 address field of the packet. SDN switches are preconfigured with rules that allow them to decide the outgoing interface of each incoming packet simply by "ORing" the packet's forwarding identifier with the identifiers of all outgoing interfaces.

#### *2.2. CoAP and CoAP Group Communication*

CoAP [8] is a lightweight protocol, designed to be the "HTTP of the IoT." CoAP resources are identified by a URI scheme, similar to HTTP URIs, and the CoAP interaction model is similar to the client–server model of HTTP. Therefore, IoT endpoints act as CoAP "servers", exposing one or more CoAP URIs that can be accessed by CoAP "clients" using a suitable CoAP "method" .

CoAP group communication is a CoAP extension that allows CoAP clients to retrieve (or set) resources from a group of CoAP servers, e.g., retrieve the temperature measurements from all sensors of a building, turn on and off all the lights of a smart city, etc. An

approach for realizing CoAP group communication is using IP multicast (Section 2 of [2]). With this approach, CoAP servers belonging to the same group join an IP multicast address, and CoAP clients learn the IP multicast address of a group using DNS resolution. Then, CoAP clients can send CoAP requests to an IP multicast address and receive the corresponding response(s) using unicast. Nevertheless IP multicast is not the only option; other underlay networking architectures can be used instead. For example, as as we discuss in the following section, our solution relies on SDN to implement one-to-many communication.

#### *2.3. Web of Things*

The goal of W3C's Web of Things (WoT) working group is to improve the interoperability and usability of the Internet of Things (IoT) [9] by specifying universal means for accessing IoT devices. This goal is achieved by providing building blocks that leverage and extend existing, standardized Web technologies in the context of IoT. Such a building block is the Thing Description specification draft [3].

A Thing Description (WoT-TD) is a JSON-LD [10] document that describes the "metadata" and "interfaces" of a "thing", where a thing can be a physical IoT device or a virtual entity that is composed of multiple IoT devices. An interface can be a "property", an "action", or an "event", that can be accessed using a Web technology such as CoAP or HTTP. A WoT-TD describes how these interfaces can be accessed by specifying suitable URIs, security policies, and other information that can be used by an interested client.

Being encoded using JSON-LD, a WoT-TD includes a context property, which is an array of URLs pointing to documents that include "vocabulary" terms. All WoT-TD include the "https://www.w3.org/2019/wot/td/v1" context, but additional contexts can be added, allowing the extension of the WoT-TD vocabulary (see also Section 7.1 of [3] for more information).

#### **3. Overview**

#### *3.1. System Entities and Security Assumptions*

Our solution considers an SDN network that interconnects IoT *endpoints* acting as CoAP servers with IoT service clients. Each IoT endpoint owns an Ed22519 public key [11], denoted by *EndpointID*. Network operators maintain a list of *EndpointID* identifiers belonging to authorized IoT devices. IoT devices are connected to the SDN network through an access device; the type of this device depends on the available communication technology (e.g., WiFi, ZigBee, LoRa, etc.); nevertheless, our solution is oblivious to used technology. Access devices are connected to edge switches acting as the network attachment point (NAP), and it is assumed that there are mechanisms that allow NAPs to access this list of authorized IoT devices. Therefore, it should be not possible for an attacker to join a network by impersonating an authorized IoT device inside the SDN network. Similarly, the network operator owns a well-known Ed22519 public key, denoted by *NetworkID*, which acts as the root of trust in our system; all endpoints are preconfigured with this key, and all NAPs can generate signatures using the private key that corresponds to a *NetworkID*. Whenever a key is included in a text-based file, we are using its Base64url encoding [12].

IoT devices provide access to resources. We focus on resources that can be accessed using CoAP and CoAP group communication.

Additionally, we consider that the SDN controller knows the full network topology, and it is capable of constructing forwarding paths from an *EndpointID* toward one or more *EndpointID* identifiers (see also Section 2.1). These paths are identified by a Bloom filter-based identifier denoted as *FwdID*. Finally, we consider that there is a well-known *FwdID* that can be used by endpoints to broadcast packets in the network.

Our solution is focused on IoT endpoints acting as CoAP servers; for this reason, we neither consider clients as part of our threat model nor are we concerned with client-facing security operations such as client authentication and authorization.

#### *3.2. IoT Device Onboarding*

Each IoT device is preconfigured with a WoT-TD file for the resources it provides. An example of a WoT-TD is one that includes an ultrasonic sensor deployed in a stadium, which can be seen in Listing 1. Lines 1–5 define the *context* of the WoT-TD file and include the identifier of the IoT device, i.e., the *EndpointID*. This example also includes an *action* used for "turning off" the sensor (line 8). This action can be invoked using either plain CoAP (lines 10–13) or CoAP group communication (lines 14–23). As it can be observed, this action can be invoked through two different groups, one representing "all sensors of the stadium" (line 15) and another representing "all sensors of a city" (line 20).

**Listing 1.** An example of a WoT-TD file.


In order for an IoT device to join the network, it establishes a (D)TLS communication channel with a NAP. The (D)TLS handshake uses the "client authentication" option. The goal of this handshake is to allow the IoT device to verify that the NAP knows the private key that corresponds to *NetworkID*, and the NAP to verify that the IoT device is the owner of *EndpointID*.

As a next step, the IoT device sends its WoT-TD file to the NAP, and the NAP verifies that it includes the same *EndpointID* used during the handshake, as well as that the *EndpointID* is in the list of authorized identifiers. Then, the NAP signs the WoT-TD file using a *linkeddata proof* (LDP) [13]. An LDP is a mechanism for ensuring the authenticity and integrity of linked-data documents, such as WoT-TD files, which is extensible and supports contemporary cryptographic solutions, such as zero-knowledge proofs (ZKPs). An LDP is encoded using JSON, and an example of an LDP used in our system is included in Listing 2. As it can be seen, line 2 defines the type of the proof, which, in our example, is an EdDSA signature [11]; line 3 includes a timestamp indicating the proof creation time; line 4 includes information that can be used for verifying the proof, which, in our case, is the *NetworkID*; line 5 includes the

purpose of the proof, which, in this listing, is to provide an "assertion" about the integrity of the WoT-TD file; finally, line 6 is the actual proof value.

**Listing 2.** A linked-data proof used in our system.


The received proof is appended to the WoT-TD file. From this point on, the IoT device can participate in the rest of the operations of our system.

#### *3.3. SDN-Based IoT Group Communication*

Our system adapts the solution presented in [14] for providing SDN-based IoT group communication and implements IoT group communication as a two-step process. The first step involves the *advertisement* of the available resources, and the second step implements the actual CoAP *group requests*.

#### 3.3.1. Resource Advertisement

IoT devices should advertise their resources by broadcasting their WoT-TD files. As a reminder, we assume a well-known *FwdID* that can be used for broadcasting. In order to protect advertisements from replay attacks, IoT devices generate a new LDP, similar to the one they have received by the NAP, which, however, includes a *nonce*, and is generated using the private key that corresponds to *EndpointID*. Nonces in our system must not be reused within a specific time frame. This can be easily implemented by maintaining a list of used nonces: each nonce should remain in the list for the duration of the selected time frame, and devices must make sure that a nonce they send or receive is not included in that list.

Upon receiving an advertisement, clients validate the integrated LDPs. In particular, they validate that the advertisement includes an LDP that can be verified using *NetworkID*, which is "well known", and another that can be verified using *EndpointID* included in the WoT-TD file. Additionally, they verify that the latter proof is adequately fresh, and it includes a unique nonce. If all verifications are successful, each client updates a *lookup table* that includes mappings from CoAP group URIs to the corresponding *EndpointID* identifiers.

#### 3.3.2. CoAP Group Request

A CoAP client wishing to send a request to a CoAP group implements the related protocol described in [14]. From a high-level perspective the client executes the following steps:


#### **4. Implementation and Evaluation**

#### *4.1. Implementation*

We implemented our solution using Eclipse's Thingweb node-wot (https:// github.com/eclipse/thingweb.node-wot accessed on 5 August 2021) as an IoT endpoint, and libcoap library (https://libcoap.net/ accessed on 5 August 2021) for emulating CoAP clients. For the SDN underlay, we relied on the tools presented in [15], i.e., we used the Open vSwitch [16] SDN switch, the POX [17] SDN controller, and we emulated the network using the mininet network emulator [18]. Finally, we used the JSON-LD library (https: //github.com/digitalbazaar/jsonld-signatures accessed on 5 August 2021) to generate and verify LDPs.

In order to not modify libcoap to support the used SDN-based group communication, we developed a CoAP proxy that implements the related protocols; CoAP clients wishing to send a request to a group simply forward their request to the proxy using plain CoAP (see Section 5.7 of [8]). Using this approach, group communication is implemented transparently from the used CoAP library. This is a useful property since it allows the use of our solution even with constrained IoT devices, acting as a CoAP client, although using CoAP libraries with limited functionality.

We measured the time required to generate and verify an LDP in a desktop PC equipped with an Intel-i5 CPU and 4GB RAM, running Xubuntu, and a Raspberry Pi 2 Model B Rev 1.1 with a 900 MHz quad-core ARM Cortex-A7 CPU and 1GB RAM, running Raspberry Pi OS. Table 1 shows the results. The size of the corresponding base64-encoded LDP is 508 bytes.

**Table 1.** LDP generation and verification times.


#### *4.2. Security Evaluation*

The security goal of our solution is to prevent "fake" advertisements. Indeed, with our solution, only authorized IoT endpoints can advertise WoT-TD files. Furthermore, because these WoT-TD files are singed, neither an active attacker nor the IoT endpoint itself can modify them.

An active attacker in our system is able to replay valid advertisements. Although, in general, replay attacks are prevented by the use of the *nonce*, there can be cases in which the replayed advertisement is received before the real one. In these cases, an endpoint will believe that the attacker is a legitimate IoT device and that the real advertisement was a replayed one. Although this attack cannot be prevented in a straightforward way, we argue that its impact is limited, and it can be easily detected and i mitigated. Advertisements in our system do not contain any location-specific information, since *EndpointID* identifiers are just public keys. Therefore, if an *EndpointID* still provides the advertised resources, the attack will have no impact apart from the added network overhead. Moreover, advertisements in our system are broadcasted; hence, it will be trivial for a monitoring entity to detect the replay attack. Finally, we consider an SDN-based architecture, in which a controller can remove any endpoint from the network in a straightforward manner.

Similarly, an attacker that has access to the private key that corresponds to an *EndpointID* can only sent *valid* advertisements of WoT-TD files belonging to the corresponding IoT device, i.e., since the *EndpointID* is included in the WoT-TD, the attacker cannot use the breached key to sign an advertisement of another IoT device. Therefore, the impact of this attack is similar to the impact of the replay attack.

From a security perspective, the most critical component of our solution is the private key that corresponds to *NetworkID*. If this key is compromised, then it must be revoked; hence, all endpoints must be reconfigured with the new *NetworkID*, and all LDPs must be regenerated.

#### *4.3. Private Advertisements Using ZKPs*

*Zero-knowledge proofs* (ZKP) are a class of proofs in which a *prover* can prove to a *verifier* the knowledge of a value without revealing what the value is [19,20]. In the context of our system, ZKPs can be used by a user in order to generate a WoT-TD that reveals only affordances that are accessed through CoAP group communication. In order to achieve this, the proof of the TD signature must have been generated using an appropriate signature algorithm. In our implementation, we used the BBS+ linked signature algorithm for this purpose [21]. This signature scheme makes use of BLS12-381 pairing-friendly keys [22]. In a WoT-TD that contains a BBS+ signature, a subset of the affordances can be hidden by "framing" the original WoT-TD in a JSON-LD frame [23]. A *JSON-LD frame* can be seen as a filter that, when applied to a JSON-LD document (e.g., a W3C-compliant VC), it outputs a new JSON-LD document that contains only a subset of the fields of the original document. Table 2 shows the time required to generate and verify an LDP proof, using the same endpoints as in Section 4.1, for a WoT-TD file that includes four affordances, three of which are hidden. For this purpose, we used node.js and the jsonld-bbs library, (https://github.com/mattrglobal/jsonld-signatures-bbs accessed on 5 August 2021), which handles JSON-LD objects and uses BLS12-381 keys to generate BBS+ ZKPs. The size of the corresponding base64-encoded LDP is 891 bytes.

**Table 2.** LDP generation and verification times when BBS+ is used.


As can be seen from this Table, LDP generation and verification in the Raspberry Pi requires approximately 1 s. Nevertheless, we are using an old device and an implementation written in node.js; therefore, there is significant space for improvement. Additionally, these signatures have to be calculated every time a new WoT description file is advertised; this process does not have to take place often—its frequency can be in the order of hours.

#### **5. Related Research**

Many research efforts provide solutions for protecting the confidentiality of IoT group communication messages, e.g., using group object security for constrained restful environments (OSCORE) [24], DTLS with pre-shared keys among group members [25,26], attribute-based encryption [27], or even by relying on the information-centric networking (ICN) paradigm [28]. These solutions are concerned with the establishment of a secret key that is used for encrypting data [24,28] or the communication channels [25,26]. Such a key can be derived by a pre-shared symmetric key, a public key, or by the attributes of the communicating endpoints. Our solution is orthogonal to these approaches since our goal is to make sure that a client receives CoAP responses only from authorized servers.

Our work considers an SDN-based underlay architecture used instead of IP multicast for implementing group communication. Many related efforts are considering other alternatives to IP multicast, including the use of bit index explicit replication (BIRE) [29], MPL [30], and ICN [31]. We see these efforts complementary to our approach since our solution is agnostic to the underlying mechanism; therefore, it could be used with any of them.

Some related solutions use identity-based signature (IBS) to achieve similar goals with our work (see, for example, [32]). Although IBS removes the need for public keys, it introduces computational overhead, and it suffers from the so-called key escrow problem, since there is a single entity (the key generator) that knows all private keys. Our solution uses Ed25519 keys, which are 32 bytes long; hence, the gains, in terms of communication overhead of using an identity rather than an Ed25519 key, are small.

Our solution is designed for IoT devices and gateways that support the WoT specification. However, in recent years, a number of related technologies have emerged. For

example, under the umbrella of the *European IoT Platform Initiative* (https://iot-epi.eu/ accessed on 5 August 2021) a number of IoT gateway technologies were developed, by projects such as symbIoTe (https://iot-epi.eu/project/symbiote/ accessed on 5 August 2021), AG-ILE (https://iot-epi.eu/project/agile/ accessed on 5 August 2021), and Interiot (https: //iot-epi.eu/project/inter-iot/ accessed on 5 August 2021). These efforts are now stalled. Since the only requirement of our solution is that device descriptions are encoded using JSON, we believe that it can be easily adapted for other gateway technologies.

Our system uses public keys for identifying IoT endpoints. A relevant technology that can be used instead is that of *decentralized identifiers* (DIDs) [33]. DIDs are closely related to LDPs. Additionally, when applied to the IoT, DIDs have some interesting security and privacy properties [34].

#### **6. Conclusions**

In this paper, we presented a security solution for managing group membership in IoT group communication. In particular, we leveraged linked-data proofs to assure that only valid group members can "advertise" their available resources. Our solution has intriguing security properties since it is a resilient event to private key breaches. Linked-data proofs allow the use of zero-knowledge proofs; our solution leverages this property in order to implement "selective disclosure" of available resources.

Future work in this area includes the integration of our solution with content confidentiality mechanisms (e.g., group OSCORE).

**Author Contributions:** Investigation, B.A. and N.F.; Project administration, B.A.; Software, N.F.; Writing—review & editing, B.A. and N.F. All authors have read and agreed to the published version of the manuscript.

**Funding:** This research was funded by Deputyship for Research & Innovation, Ministry of Education in Saudi Arabia grant number 277.

**Data Availability Statement:** Not Applicable, the study does not report any data.

**Acknowledgments:** The authors extend their appreciation to the Deputyship for Research & Innovation, Ministry of Education in Saudi Arabia for funding this research work through the project number (227).

**Conflicts of Interest:** The authors declare no conflict of interest.

#### **References**


## *Article* **A Bidirectional Trust Model for Service Delegation in Social Internet of Things**

**Lijun Wei 1, Yuhan Yang 1, Jing Wu 1, Chengnian Long 1,\* and Yi-Bing Lin 2,3,\***


<sup>3</sup> College of Humanities and Sciences, China Medical University, Taichung 406, Taiwan

**\*** Correspondence: longcn@sjtu.edu.cn (C.L.); liny@csie.nctu.edu.tw (Y.-B.L.)

**Abstract:** As an emerging paradigm of service infrastructure, social internet of things (SIoT) applies the social networking aspects to the internet of things (IoT). Each object in SIoT can establish the social relationship without human intervention, which will enhance the efficiency of interaction among objects, thus boosting the service efficiency. The issue of trust is regarded as an important issue in the development of SIoT. It will influence the object to make decisions about the service delegation. In the current literature, the solutions for the trust issue are always unidirectional, that is, only consider the needs of the service requester to evaluate the trust of service providers. Moreover, the relationship between the service delegation and trust model is still ambiguous. In this paper, we present a bidirectional trust model and construct an explicit approach to address the issue of service delegation based on the trust model. We comprehensively consider the context of the SIoT services or tasks for enhancing the feasibility of our model. The subjective logic is used for trust quantification and we design two optimized operators for opinion convergence. Finally, the proposed trust model and trust-based service delegation method are validated through a series of numerical tests.

**Keywords:** trust model; social internet of things; service delegation

#### **1. Introduction**

As the 4th industrial revolution and the development of future social interconnection technology, internet of things (IoT), following the internet, brings tremendous changes in people's lives [1–3]. With the continuous intelligence of hardware devices and the maturity of edge computing technology, IoT will have greater scalability [4,5]. Integrating the concept of socialization into the IoT system, the social internet of things (SIoT) [6,7], as a new service paradigm, improves the interoperability among IoT objects and enhances the service efficiency in industry applications. The objects will establish the relationship with each other and collaborate on services without human intervention, which make the objects more autonomous in the process of IoT service. Moreover, the structure of SIoT boosts the network navigability and scalability, which enhances the service discovery and resource acquisition. Currently, the SIoT paradigm has been widely applied in various application scenarios, such as vehicular social networks [8–11], mobile crowdsensing [12–16], datadriven smart city [17–20], etc.

In SIoT, each object (e.g., intelligent sensors, smartphone, and video camera) can be a service requester (SR) or service provider (SP), according to its own motivations. The SR will broadcast the service request, such as collecting sensing tasks or urban noise data, and provide some rewards to the SP. On the other hand, the SP will provide the specific service, such as sharing information or computation resources to the SR, to receive some rewards from the SR. Each IoT object can autonomously determine which service to initiate and which object to delegate within a given set of candidate objects. By this method, the service discovery, interaction, and execution will be optimally implemented.

**Citation:** Wei, L.; Yang, Y.; Wu, J.; Long, C.; Lin, Y.-B. A Bidirectional Trust Model for Service Delegation in Social Internet of Things. *Future Internet* **2022**, *14*, 135. https:// doi.org/10.3390/fi14050135

Academic Editor: Christoph Stach

Received: 9 April 2022 Accepted: 26 April 2022 Published: 29 April 2022

**Publisher's Note:** MDPI stays neutral with regard to jurisdictional claims in published maps and institutional affiliations.

**Copyright:** © 2022 by the authors. Licensee MDPI, Basel, Switzerland. This article is an open access article distributed under the terms and conditions of the Creative Commons Attribution (CC BY) license (https:// creativecommons.org/licenses/by/ 4.0/).

Although the SIoT paradigm will improve the quality of services to a certain extent, it also may suffer from various types of attacks due to the presence of malicious objects [21]. Some malicious objects may launch bad-mouthing or cheating attacks to affect the decision process of service delegation [22]. To address this issue, in recent years, some works in the literature have presented various trust models to solve the problems of trust establishment and relationship maintenance among objects in SIoT [23,24]. Trust is a complex and comprehensive concept in SIoT [25,26]. Specifically, trust not only reflects the security and reliability at the IoT system level, but also reflects the degree of cooperation between two IoT objects when establishing an interactive relationship. The establishment of trust will stimulate cooperation and improve security in the process of service [27–29]. Castelfranchi and Falcone introduced a systematic socio-cognitive trust theory [27]. They proposed a layered model for trust, which consists of five basic ingredients: trustor, trustee, task, goal, and context. They also proposed and analyzed the important characteristics, including integrated, socio-cognitive, multi-factor and multi-dimensional, dynamic, non-prescriptive, etc. The proposed trust theory can be used as a theoretical foundation for analyzing the trust issue of SIoT. Xia et al. combined the fuzzy logic method to solve the trustworthiness convergence issue and proposed a lightweight mechanism for service discovery based on directed acyclic graph (DAG) [28]. On this basis, Xia et al. proposed a trustworthiness inference framework which combines a kernel-based nonlinear multivariate grey prediction model and fuzzy logic method to quantify the trust [29]. Amin et al. presented a classified catalog of friendliness and trust in SIoT. They described the key ingredients and challenges of friendliness- and trust-based approaches, which contributes to the analysis of the effectiveness of the trust model [30]. Narang and Kar proposed a hybrid trust management framework based on probabilistic neighborhood overlap, which considers the resourceconstrained IoT devices [31]. Moreover, they analyzed the various attack scenarios, such as slandering/bad-mouthing attack, Sybil attack, self-promoting attack, and ballot stuffing attack to demonstrate the effectiveness of the proposed model. Chen et al. proposed an integrated trust evaluation model which combines direct and indirect trustworthiness [32,33]. Moreover, they further proposed a series of new metrics, such as friendship similarity, social contact similarity, and community of interest similarity to quantify the indirect trust evaluation. They also applied the typical application scenarios, including air pollution detection and augmented map travel assistance, to illustrate the feasibility of the proposed model. In order to comprehensively compare the recent studies along with advantages and disadvantages, we presented detailed comparison of various works in the literature on the SIoT trust model in our previous work [34].

However, the current research on trust model in SIoT still faces three important challenges. First, most works focus on the unidirectional trust evaluation from the SR to the SP. The evaluation of the trustworthiness of SR is ignored, which may cause the trust crisis from the SPs to the SR. The SPs may gradually lose enthusiasm if they suffer prejudiced treatment of the malicious SR. Second, the trust model and service delegation are context- or environment dependent. The properties of the same task are different in different contexts or environments. Third, the decision of service delegation should not only consider the trust of SPs, but also the utility of the SR. In addition, the correlation between trust and utility is ambiguous.

To address the above challenges, we propose a bidirectional trust model and trustbased service delegation approach by comprehensively considering the trust and utility of service requesters and providers. We combine the social trust theory and characteristics of IoT tasks to formalize the trust evaluation and service delegation model. The main contributions of this paper are as follows:

• In order to improve the quality of the IoT service, we propose the bidirectional evaluation and selection model between the SRs and SPs to formulate the process of service or task in SIoT, thus preventing the malicious behaviors of SRs and SPs.


The remainder of the paper is organized as follows: the system overview and problem statement are presented in Section 2. On this basis, we present the trust and service delegation model, including the trust quantification method and integrated service delegation mechanism in Section 3. In Section 4, in order to demonstrate the feasibility of proposed trust model, we present a series of experiments. In Section 5, we conclude the paper and summarize the contributions. Moreover, some pending research issues are discussed for further research.

#### **2. System Overview and Problem Statement**

We consider a general system model in SIoT which consists of five ingredients: (1) service requester (SR), (2) service provider (SP), (3) intermediate object, (4) the context, and the (5) service/task. The life cycle of a task or service is shown in Figure 1. The first step that the SR will perform is to determine the content of the task, including the context, property and goal. It will also publish the task request information. Then, after receiving the message of the task request, the SPs will determine whether to respond to the request by evaluating the trustworthiness of the SR. If the SR is trustworthy from the perspective of the SP, the SP will send a respond message which contains the task price, which is calculated by considering the cost of the task performance. After receiving some response, the SR will delegate the task to the specific SP based on the trust model and the consideration of utility. Then, the delegated SP will perform the task and submit the result. After receiving the result of the task from the delegated SPs, the SR and SP will evaluate each other about their behaviors and update the trust model.

**Figure 1.** The operation framework of the task/service cycle.

Different from the traditional trust-based service delegation model in SIoT, we combine the bidirectional evaluation to construct the trust model and adopt the utility optimization to formulate the service delegation problem. On the one hand, most of the current literature assumed that SR is reliable, which means the trust between the SR and SP is unidirectional. This assumption may be reasonable and useful in the small-scale network or SR-centric situation. However, in the open and large-scale SIoT scenarios, the SR may not be reliable. If there is no bidirectional evaluation, a malicious SR may damage the SP's privacy, or it may delay a payment after the SP submits the task results. On the other hand, the current literature often employs trustworthiness to determine which SP should be delegated, but there is a lack of consideration for utility issues. To this end, we design the trust-based utility formulation for service delegation.

In order to facilitate the formal description, we divide the entire process into four steps, focusing on the decision-making problem of the object in the process of IoT tasks or services.

#### *2.1. Step 1: The SR Determines the Content of the Task in the Specific Context*

In the first step, the SR *ui* will comprehensively consider the goal of task and the context to construct the content of the task. A task includes the several necessary properties, which reflect the SR requirements. Formally, the task is denoted by *<sup>ϕ</sup>* = {*p<sup>ϕ</sup>* = {*p*<sup>1</sup> *<sup>ϕ</sup>*, *p*<sup>2</sup> *<sup>ϕ</sup>*, ... , *p<sup>m</sup> <sup>ϕ</sup>* }|*Gϕ*}*C*, where *C* is the context of the task *ϕ*. *p<sup>ϕ</sup>* represents the properties of task *ϕ* in the context *C*, and *G<sup>ϕ</sup>* is the goal of the SR *ui* for publishing the task *ϕ*.

#### *2.2. Step 2: The SPs Determine Whether to Response the Task Request of the SR*

After receiving the request from the SR *ui*, the SPs will evaluate the trustworthiness of the SR *ui* based on the direct interaction records and some recommendation opinions from several intermediate objects. The set of SPs is denoted by *V* = {*v*1, *v*2, ... , *vn*}. The set of intermediate objects, which have some interactions with the SR, is denoted by *INSR* = {*r*1,*r*2, ...}. The trustworthiness of the SR *ui* from the viewpoint of the SP *vj* is formulated as −→*<sup>T</sup> ui*←*vj*

$$\overrightarrow{T}\_{\
u\_{i}\leftarrow\upsilon\_{j}}(\boldsymbol{\varrho}) = f\_{\rm ct}(\overrightarrow{T}\_{\
u\_{i}\leftarrow\upsilon\_{j}}^{\scriptstyle d}(\boldsymbol{\varrho}), \{\overrightarrow{T}\_{\
u\_{i}\leftarrow\upsilon\_{k}}^{\scriptstyle \rm rec}(\boldsymbol{\varrho})\}\_{k=1,2,\ldots}),\tag{1}$$

where −→*<sup>T</sup> <sup>d</sup> ui*←*vj* (*ϕ*) denotes the direct trust vector of the SR *ui* from the viewpoint of the SP *vj*. Additionally, −→*<sup>T</sup> rec ui*←*rk* (*ϕ*) denotes the recommendation trust of the SR *ui* from the viewpoint of the intermediate object *rk*. The function *fct* is the convergence function of the trust opinions from the different sources. Based on the evaluation result of the SR trust, the SP will determine whether to respond to the task request by solving the following formulation:

$$\operatorname{Respons}\_{u\_i \leftarrow v\_j} (\mathfrak{q}) \begin{cases} \quad \psi\_{v\_j}(\mathfrak{q}), & \operatorname{g}(\overrightarrow{T}\_{\
u\_i \leftarrow v\_j}(\mathfrak{q})) \ge th\_{\mathcal{v}}(\mathfrak{q})\\ \quad \operatorname{null}, & \operatorname{g}(\overrightarrow{T}\_{\
u\_i \leftarrow v\_j}(\mathfrak{q})) < th\_{\mathcal{v}}(\mathfrak{q}). \end{cases} \tag{2}$$

where *thv*(*ϕ*) is a response threshold set by *vj* for the task *ϕ*, and *ψvj* (*ϕ*) denotes the price that SR *ui* needs to pay to the SP *vj* if *ui* delegates *vj* to perform task *ϕ*. *g*(·) denotes the function of the trustworthiness calculation.

#### *2.3. Step 3: The SR Delegates the Task to the SP*

After receiving several responses, the SR *ui* will consider the factors of trust and utility to make a decision of service delegation. Similar to the process of trust evaluation of the SR from the viewpoint of the SP in step 2, the trust of the SP *vj* from the viewpoint of the SR *uj* is formulated as

$$\overrightarrow{T}\_{v\_{\rangle}\leftarrow u\_{i}}(\varphi) = f\_{ct}(\overrightarrow{T}\_{v\_{\rangle}\leftarrow u\_{i}}^{\sharp}(\varphi), \{\overrightarrow{T}\_{v\_{\rangle}\leftarrow s\_{k}}^{\flat}(\varphi)\}\_{k=1,2,\ldots}),\tag{3}$$

where *sk* denotes the intermediate objects which have some interactions with the SP *vj*. Based on the trust analysis, the SR will determine the delegated SP by solving the following formulation:

$$\begin{aligned} DSB &= \underset{v\_j}{\text{arg}\max} \ f\_{\text{flu}} (\overrightarrow{T}^{\sharp}\_{v\_j \leftarrow u\_i}(\varphi), \psi\_{v\_j}(\varphi)),\\ \text{s.t.} \quad &g(\overrightarrow{T}^{\flat}\_{v\_j \leftarrow u\_i}(\varphi)) \ge t h\_{\text{ul}}(\varphi) \end{aligned} \tag{4}$$

where *ftu* is the delegation function that calculates the integrated index for service delegation. *thu*(*ϕ*) is a trust threshold set by *ui* for the task *ϕ*.

#### *2.4. Step 4: The Delegated SP Performs the Task and Submits the Result, and Then the SR and SP Will Mutually Comment Each Other*

After receiving the delegation message from the SR, the delegated SP (we assume *vj*) will perform the task and submit the result. After that, the SR will evaluate the result according to the accuracy, real-time, etc., of the task performance to decide the success or failure of the task. The SR's evaluation of the task is denoted by <sup>Υ</sup>*t<sup>ϕ</sup> vj*←*ui* (*ϕ*), where *t<sup>ϕ</sup>* is the occurred time of the task *ϕ*. If the SR is satisfied according to the SP's performance, the <sup>Υ</sup>*t<sup>ϕ</sup> vj*←*ui* (*ϕ*) will be set 1, and it will be set −1 if the SR is unsatisfied. Similarly, the SP will also evaluate the SR's behavior in the process of the task, which is denoted by <sup>Υ</sup>*t<sup>ϕ</sup> ui*←*vj* (*ϕ*). If the SP is satisfied, then the <sup>Υ</sup>*t<sup>ϕ</sup> ui*←*vj* (*ϕ*) will be set 1, and it will be set −1 if the SP feels unsatisfied.

#### *2.5. Problem Statement*

According to the previous description, we can find that in the entire service delegation process, the most important part lies in the rules for mutual trust evaluation between objects, and how to use the trust evaluation information to make decisions. The first important problem is the structuralization of the interactions and the calculation of the direct trust.

*Problem Statement 1: Based on historical interaction records between object A and object B, how does object A determine the direct trust of object B?*

The recommended trust opinions from intermediate objects can be great references for object A to evaluate the trust of object B. However, trust opinions from different sources should have different degrees of confidence. For example, we usually believe in information from reliable sources. Therefore, how to effectively quantify the confidence of information from different sources will be the second important problem.

*Problem Statement 2: When intermediate object C provides A with trust opinions about object B, how will A integrate the opinions of C?*

The success of task execution is seriously related to the delegation decision of the SR, so in the process of service delegation, the SR must carefully evaluate the reliability of SPs. Establishing trust is a suitable way to evaluate the reliability of an object. However, the SR will not only consider trust, but also its own benefits in the delegation process. Therefore, how to comprehensively consider both trust and utility so as to ensure that a relatively reliable SP is selected and optimize the utility of SR is the third important problem.

*Problem Statement 3: According to the trust of the candidate objects, how does object A delegate the task?*

In summary, *Problem 1* corresponds to the quantitative calculation of *T<sup>d</sup> vj*←*ui* (*ϕ*). *Problem 2* corresponds to the formulation of Equation (1). In addition, *Problem 3* corresponds to the formulation of Equation (4).

#### **3. Trust and Service Delegation Model**

#### *3.1. Trust Model*

In our trust model, the direct interactions and indirect opinions are comprehensively considered. We employ subjective logic for the trust analysis. The results of the trust analysis and utility analysis are integrated for the decision of the service delegation. The whole design framework is shown in Figure 2. Next, we detail the entire trust analysis and service delegation process.

**Figure 2.** The design framework of the trust model and service delegation.

#### 3.1.1. Subjective Logic

Subjective logic is an uncertain probabilistic logic that was initially introduced by Audun Jøsang to address formal representations of trust [35]. The subjective logic constructs a bijective mapping between opinion space and evidence space, which can help SR to form its own opinion based on the existing direct evidence, and to integrate the recommendation opinions from others to form a comprehensive opinion.

**Definition 1** (Opinion Space)**.** *A's direct opinion about object B for the task ϕ is a vector:*

$$\overrightarrow{T}\_{B\gets A}(\varphi) = (b\_{B\gets A}(\varphi), d\_{B\gets A}(\varphi), u\_{B\gets A}(\varphi), a\_{B\gets A}(\varphi)),\tag{5}$$

*where bB*←*A*(*ϕ*) *represents the degree to which A believes B will successfully perform the task ϕ, and dB*←*A*(*ϕ*) *represents the degree to which A disbelieves that B will successfully perform the task ϕ. uB*←*A*(*ϕ*) *represents the degree to which A is uncertain about whether B will successfully perform the task ϕ, and aB*←*A*(*ϕ*) *is the base rate. The opinion satisfies the additivity requirement as follows:*

$$
\mu\_{B \gets A}(\varphi) + d\_{B \gets A}(\varphi) + \mathfrak{u}\_{B \gets A}(\varphi) = 1,\tag{6}
$$

*and the projected probability of the opinion* −→*<sup>T</sup> <sup>B</sup>*←*A*(*ϕ*) *is defined as*

$$
\hat{T}\_{B \gets A}(\varphi) = b\_{B \gets A}(\varphi) + a\_{B \gets A}(\varphi) u\_{B \gets A}(\varphi). \tag{7}
$$

In our trust model, we use −→*<sup>T</sup> <sup>d</sup> <sup>B</sup>*←*A*(*ϕ*) to represent the direct trust vector of object B from the viewpoint of object A for the task *ϕ*. *T*ˆ *<sup>d</sup> <sup>B</sup>*←*A*(*ϕ*) is used for representing the projected trustworthiness of object B.

Evidences are fundamental for forming opinions, which can be presented as a series of the binary comments such as "satisfaction" and "dissatisfaction". The amount of evidence will affect the certainty of the opinion. In subjective logic, the Beta function is used for constructing the evidence space. The probability density function is as follows:

$$Beta(p\_{x}, a, \beta) = \frac{\Gamma(a + \beta)}{\Gamma(a)\Gamma(\beta)} p\_{x}^{a-1} (1 - p\_{x})^{\beta - 1},\tag{8}$$

where Γ() is the gamma function. The beta function can be used to represent the probability distribution of binary events. Therefore, the evidence space can be defined as follows:

**Definition 2** (Evidence Space)**.** *An evidence space can be depicted by a beta probability distribution:*

$$Beta\left(\overrightarrow{T}^{\wedge d}\_{B \leftarrow A}(\,\,\!\!\!\!\!\!\/), \,\alpha\_{B \leftarrow A}(\,\,\!\!\!\/), \,\beta\_{B \leftarrow A}(\,\,\!\!\/), \,\right) \tag{9}$$

*where* −→*<sup>T</sup> <sup>d</sup> <sup>B</sup>*←*A*(*ϕ*) *represents the direct trust vector of B from the viewpoint of A in evidence space. αB*←*A*(*ϕ*) *and βB*←*A*(*ϕ*) *are defined as:*

$$\begin{cases} \begin{array}{l} a\_{B \leftarrow A}(\varphi) = \gamma\_{B \leftarrow A}(\varphi) + 2a\_{B \leftarrow A}(\varphi) \\ \beta\_{B \leftarrow A}(\varphi) = \overline{\gamma}\_{B \leftarrow A}(\varphi) + 2(1 - a\_{B \leftarrow A}(\varphi)) \end{array} \tag{10}$$

*where <sup>γ</sup>B*←*A*(*ϕ*) *and <sup>γ</sup>B*←*A*(*ϕ*) *are the evidence strength which is based on the historical interactions between objects A and B. γB*←*A*(*ϕ*) *denotes the positive evidence strength, which indicates that the B is trustworthy. <sup>γ</sup>B*←*A*(*ϕ*) *denotes the negative evidence strength, which indicates that B is untrustworthy.*

*The expected probability E*( −→*<sup>T</sup> <sup>d</sup> <sup>B</sup>*←*A*(*ϕ*)) *is defined as the projected trustworthiness in evidence space, which is expressed as follows:*

$$\begin{split} \hat{T}\_{B \gets A}^{d}(\boldsymbol{\varrho}) &= E(\overline{T}\_{B \gets A}^{\text{\textquotedblleft}d}(\boldsymbol{\varrho})) = \frac{\alpha\_{B \gets A}(\boldsymbol{\varrho})}{\alpha\_{B \gets A}(\boldsymbol{\varrho}) + \beta\_{B \gets A}(\boldsymbol{\varrho})} \\ &= \frac{\gamma\_{B \gets A}(\boldsymbol{\varrho}) + 2a\_{B \gets A}(\boldsymbol{\varrho})}{\gamma\_{B \gets A}(\boldsymbol{\varrho}) + \overline{\gamma}\_{B \gets A}(\boldsymbol{\varrho}) + 2} \end{split} \tag{11}$$

The bijective mapping between the trust vector in opinion space and the trust vector in the evidence space emerges from the intuitive requirement *T*ˆ *<sup>d</sup> <sup>B</sup>*←*A*(*ϕ*) = *<sup>T</sup><sup>d</sup> <sup>B</sup>*←*A*(*ϕ*), which is defined as follows.

**Definition 3** (Mapping between opinion space and evidence space)**.**

$$\begin{cases} \begin{array}{l} b\_{B \gets A}(\varphi) = \frac{\gamma\_{B \gets A}(\varphi)}{\gamma\_{B \gets A}(\varphi) + \overline{\gamma}\_{B \gets A}(\varphi) + 2} \\ d\_{B \gets A}(\varphi) = \frac{\overline{\gamma}\_{B \gets A}(\varphi)}{\gamma\_{B \gets A}(\varphi) + \overline{\gamma}\_{B \gets A}(\varphi) + 2} \\ \mu\_{B \gets A}(\varphi) = \frac{2}{\gamma\_{B \gets A}(\varphi) + \overline{\gamma}\_{B \gets A}(\varphi) + 2} \end{array} \tag{12}$$

$$\begin{cases} \gamma\_{B \leftarrow A}(\varphi) = \frac{2b\_{B \leftarrow A}(\varphi)}{\mu\_{B \leftarrow A}(\varphi)}\\ \overline{\gamma}\_{B \leftarrow A}(\varphi) = \frac{2d\_{B \leftarrow A}(\varphi)}{\mu\_{B \leftarrow A}(\varphi)} \end{cases} \tag{1.3}$$

3.1.2. Direct Trust

In this paragraph, we introduce the direct trust which is based on the direct interaction records between objects A and B.

#### • **Task Similarity**

Due to the different context of each task, the importance of different past interaction comments to the current task is different and should be decided by the task similarity. To this end, we use the Jaccard Similarity Index to estimate the similarity of two task in the different context, which is expressed as follows.

$$Sim(\varphi, \varphi') = J(p\_{\varphi}, p\_{\varphi'}) = \frac{|p\_{\varphi} \cap p\_{\varphi'}|}{|p\_{\varphi} \cup p\_{\varphi'}|} \tag{14}$$

For a simple example, we assume there are, in total, four properties, such as {"High Definition", "Least Memory", "Location Range", "Real-Time", and "Measurement Accuracy"}. If the property is required in the task, then the corresponding value of the property vector is set to "1" and otherwise "0". If the *ϕ* is a video monitoring task, then the *pϕ* may be equal to {1, 1, 1, 1, 0}. If the *ϕ* is crowdsensing noise monitoring, then the *pϕ* may be equal to {0, 1, 1, 0, 1}. Then the similarity between *ϕ* and *ϕ* is equal to 2/5.

#### • **Time Window**

The evidence is time dependent. Recent task performance has a greater effect than the older task on the trust evaluation of the object. The time window is presented for the time-dependent strength of single evidence, which is shown in Figure 3.

**Figure 3.** The design of time window for trust evaluation.

Based on the time window, the strength of single evidence can be expressed as follows:

$$\mathbf{Y}\_{B \gets A}^{t\_{\mathcal{P}}}(\boldsymbol{\varrho}) = \begin{cases} \mathbf{Y}\_{B \gets A}^{t\_{\mathcal{P}}}(\boldsymbol{\varrho}) e^{-\lambda \left(t\_{\mathcal{E}} - t\_{\mathcal{P}}\right)}, & |t\_{\mathcal{E}} - t\_{\mathcal{P}}| \le \theta\_t. \\\ 0, & |t\_{\mathcal{E}} - t\_{\mathcal{P}}| > \theta\_t. \end{cases} \tag{15}$$

where *tc* denotes the current time and *λ* denotes the decay factor, which affects the rate of decay of the evidence strength.

#### • **Evidence Strength**

By aggregating the valid direct interaction records, that is, a batch of valid single evidence, we can calculate the total strength of direct evidences as follows:

$$\gamma\_{B \leftarrow A}^{d}(\varphi) = \sum\_{\hat{\mathbf{Y}}\_{B \leftarrow A}^{t\_{\hat{\mathbf{y}}}}(\varphi') > 0} \hat{\mathbf{Y}}\_{B \leftarrow A}^{t\_{\hat{\mathbf{y}}}}(\varphi') \text{Sim}(\varphi, \varphi'), \tag{16}$$

$$\overline{\gamma}\_{B \leftarrow A}^{d}(\boldsymbol{\varrho}) = -\sum\_{\boldsymbol{\hat{Y}}\_{B \leftarrow A}^{t\_{\boldsymbol{\hat{\varrho}}}}(\boldsymbol{\varrho}^{\boldsymbol{\prime}}) < 0} \hat{\mathbf{Y}}\_{B \leftarrow A}^{t\_{\boldsymbol{\varrho}}}(\boldsymbol{\varrho}^{\boldsymbol{\prime}}) \operatorname{Sim}(\boldsymbol{\varrho}, \boldsymbol{\varrho}^{\boldsymbol{\prime}}).\tag{17}$$

#### • **Direct Trust Calculation**

By combining the methods of task similarity, time window, and evidence strength, we can calculate the direct trust vector −→*<sup>T</sup> <sup>d</sup> <sup>B</sup>*←*A*(*ϕ*) of the object B from the viewpoint of A for the task *ϕ* by substituting Equations (16) and (17) into (12). Therefore, the *problem 1* is addressed through the above design and analysis.

#### 3.1.3. Indirect Trust

In addition to direct trust evaluation, A will also ask C and D for relevant opinions about B. This paragraph solves the fusion problem of recommendation opinions by designing the discounting and consensus operators. The recommendation opinions from objects C and D are expressed as follows, respectively.

$$\overrightarrow{T}^{\text{rec}}\_{B \gets \text{C}}(\mathfrak{q}) = (b\_{B \gets \text{C}}(\mathfrak{q}), d\_{B \gets \text{C}}(\mathfrak{q}), u\_{B \gets \text{C}}(\mathfrak{q}), a\_{B \gets \text{C}}(\mathfrak{q})) \tag{18}$$

$$\overrightarrow{T}^{\text{rec}}\_{B \gets D}(\mathfrak{q}) = (b\_{B \gets D}(\mathfrak{q}), d\_{B \gets D}(\mathfrak{q}), \mathfrak{u}\_{B \gets D}(\mathfrak{q}), a\_{B \gets D}(\mathfrak{q})) \tag{19}$$

The objective in this part is to construct the suitable function *find*(·) to integrate the −→*<sup>T</sup> rec <sup>B</sup>*←*D*(*ϕ*) and −→*<sup>T</sup> rec <sup>B</sup>*←*C*(*ϕ*), which is formulated as follows:

$$\overrightarrow{T}^{\text{ind}}\_{B \gets A}(\varphi) = f\_{\text{ind}}(\overrightarrow{T}^{\text{rec}}\_{B \gets \text{C}}(\varphi), \overrightarrow{T}^{\text{rec}}\_{B \gets D}(\varphi)), \tag{20}$$

and −→*<sup>T</sup> ind <sup>B</sup>*←*A*(*ϕ*)=(*bind <sup>B</sup>*←*A*, *<sup>d</sup>ind <sup>B</sup>*←*A*, *<sup>u</sup>ind <sup>B</sup>*←*A*, *<sup>a</sup>ind <sup>B</sup>*←*A*).

#### • **Discounting and Consensus Operator**

In the subjective logic framework, the discounting rule does not have a natural interpretation of evidence handling [36]. To this end, we use the trust in opinion space to discount the trust in evidence space. The ideas and principles are shown in Figure 4. We use the symbol <sup>⊗</sup> to represent the discounting operator. Thus we have −→*<sup>T</sup> ind <sup>B</sup>*←*C*←*A*(*ϕ*) = −→*<sup>T</sup> rec <sup>B</sup>*←*C*(*ϕ*) <sup>⊗</sup> −→*<sup>T</sup> <sup>d</sup> <sup>C</sup>*←*A*(*ϕ*).

The specific discounting rule ⊗ in evidence space is shown as follows.

$$\begin{cases} \gamma\_{B \leftarrow C \leftarrow A}^{\text{ind}}(\mathfrak{p}) = \hat{\mathcal{T}}\_{\mathbb{C} \leftarrow A}^{d}(\mathfrak{q}) \gamma\_{B \leftarrow \mathbb{C}}^{\text{rec}}(\mathfrak{q})\\ \overline{\gamma}\_{B \leftarrow \mathbb{C} \leftarrow A}^{\text{ind}}(\mathfrak{q}) = \mathcal{T}\_{\mathbb{C} \leftarrow A}^{d}(\mathfrak{q}) \overline{\gamma}\_{B \leftarrow \mathbb{C}}^{\text{rec}}(\mathfrak{q}) \end{cases} \tag{21}$$

Based on Equations (12) and (21), we can calculate the indirect trust vector −→*<sup>T</sup> ind <sup>B</sup>*←*C*←*A*(*ϕ*), which is shown as follows.

$$\begin{cases} \begin{aligned} &b^{ind}\_{B\leftarrow\subset\leftarrow A}(\boldsymbol{\varrho}) = \frac{\dot{\mathcal{T}}^{d}\_{\boldsymbol{\zeta}\leftarrow A}(\boldsymbol{\varrho})b^{nc}\_{B\leftarrow\subset}(\boldsymbol{\varrho})}{\dot{\mathcal{T}}^{d}\_{\boldsymbol{\zeta}\leftarrow A}(\boldsymbol{\varrho})b^{nc}\_{B\leftarrow\subset}(\boldsymbol{\varrho}) + \dot{\mathcal{T}}^{d}\_{\boldsymbol{\zeta}\leftarrow A}(\boldsymbol{\varrho})d^{nc}\_{B\leftarrow\subset}(\boldsymbol{\varrho}) + u^{nc}\_{B\leftarrow\subset}(\boldsymbol{\varrho})} \\ &d^{ind}\_{B\leftarrow\subset\leftarrow A}(\boldsymbol{\varrho}) = \frac{\dot{\mathcal{T}}^{d}\_{\boldsymbol{\zeta}\leftarrow A}(\boldsymbol{\varrho})d^{nc}\_{B\leftarrow\subset}(\boldsymbol{\varrho})}{\dot{\mathcal{T}}^{d}\_{\boldsymbol{\zeta}\leftarrow A}(\boldsymbol{\varrho})b^{nc}\_{B\leftarrow\subset}(\boldsymbol{\varrho}) + \dot{\mathcal{T}}^{d}\_{\boldsymbol{\zeta}\leftarrow A}(\boldsymbol{\varrho})d^{nc}\_{B\leftarrow\subset}(\boldsymbol{\varrho}) + u^{nc}\_{B\leftarrow\subset}(\boldsymbol{\varrho})} \\ &u^{ind}\_{B\leftarrow\subset\leftarrow A}(\boldsymbol{\varrho}) = \frac{u^{nc}\_{B\leftarrow\subset}(\boldsymbol{\varrho})}{\dot{\mathcal{T}}^{d}\_{\boldsymbol{\zeta}\leftarrow A}(\boldsymbol{\varrho})b^{nc}\_{B\leftarrow\subset}(\boldsymbol{\varrho}) + \dot{\mathcal{T}}^{d}\_{\boldsymbol{\zeta}\leftarrow A}(\boldsymbol{\varrho})a^{nc}\_{B\leftarrow\subset}(\boldsymbol{\varrho}) + u^{nc}\_{B\leftarrow\subset}(\boldsymbol{\varrho})} \\ &a^{ind}\_{B\leftarrow\subset\leftarrow A}(\boldsymbol{\varrho}) = \dot{\mathcal{T}}^{d}\_{\boldsymbol{\zeta}\leftarrow A}(\boldsymbol{\varrho})a^{nc}\_{B\leftarrow\subset A}(\boldsymbol{\varrho}) \end{aligned} \tag{22}$$

The consensus operator is designed for integrating the recommendation opinions from different sources. We use the weighted sum method to design the consensus operator. Similar to the design idea of discounting operator, we use the trust in opinion space as weight parameters. The symbol <sup>⊕</sup> represents the consensus operator, and thus we have −→*<sup>T</sup> ind <sup>B</sup>*←*A*(*ϕ*) = −→*<sup>T</sup> ind <sup>B</sup>*←*CD*←*A*(*ϕ*) = −→*<sup>T</sup> ind <sup>B</sup>*←*C*←*A*(*ϕ*) <sup>⊕</sup> −→*<sup>T</sup> ind <sup>B</sup>*←*D*←*A*(*ϕ*). The specific consensus operator in evidence space is shown as follows.

$$\begin{cases} \begin{array}{c} \gamma\_{B \gets A}^{ind}(\boldsymbol{\varphi}) = \frac{(1 - \boldsymbol{u}\_{B \gets C \gets A}^{ind}(\boldsymbol{\varphi})) \gamma\_{B \gets C \gets A}^{ind}(\boldsymbol{\varphi}) + (1 - \boldsymbol{u}\_{B \gets D \gets A}^{ind}(\boldsymbol{\varphi})) \gamma\_{B \gets D \gets A}^{ind}(\boldsymbol{\varphi})}{(1 - \boldsymbol{u}\_{B \gets C \gets A}^{ind}(\boldsymbol{\varphi})) + (1 - \boldsymbol{u}\_{B \gets D \gets A}^{ind}(\boldsymbol{\varphi}))} \\ \end{array} \tag{23}$$
 
$$\overline{\gamma}\_{B \gets A}^{ind}(\boldsymbol{\varphi}) = \frac{(1 - \boldsymbol{u}\_{B \gets C \gets A}^{ind}(\boldsymbol{\varphi})) \overline{\gamma}\_{B \gets C \gets A}^{ind}(\boldsymbol{\varphi}) + (1 - \boldsymbol{u}\_{B \gets D \gets A}^{ind}(\boldsymbol{\varphi})) \overline{\gamma}\_{B \gets D \gets A}^{ind}(\boldsymbol{\varphi})}{(1 - \boldsymbol{u}\_{B \gets C \gets A}^{ind}(\boldsymbol{\varphi})) + (1 - \boldsymbol{u}\_{B \gets D \gets A}^{ind}(\boldsymbol{\varphi}))} \end{array} \tag{23}$$

**Figure 4.** The design of discounting operator.

#### • **Indirect Trust Calculation**

From Equations (12) and (23), we obtain the indirect trust vector −→*<sup>T</sup> ind <sup>B</sup>*←*A*(*ϕ*):

⎧ ⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎨ ⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎩ *bind <sup>B</sup>*←*A*(*ϕ*) = (1−*uind <sup>B</sup>*←*C*←*A*(*ϕ*))*uind <sup>B</sup>*←*D*←*A*(*ϕ*)*bind <sup>B</sup>*←*C*←*A*(*ϕ*)+(1−*uind <sup>B</sup>*←*D*←*A*(*ϕ*)))*ind <sup>B</sup>*←*C*←*A*(*ϕ*)*bind <sup>B</sup>*←*D*←*A*(*ϕ*) (1−*uind <sup>B</sup>*←*C*←*A*(*ϕ*))*uind <sup>B</sup>*←*D*←*A*(*ϕ*)+(1−*uind <sup>B</sup>*←*D*←*A*(*ϕ*))*uind <sup>B</sup>*←*C*←*A*(*ϕ*) *dind <sup>B</sup>*←*A*(*ϕ*) = (1−*uind <sup>B</sup>*←*C*←*A*(*ϕ*))*uind <sup>B</sup>*←*D*←*A*(*ϕ*)*dind <sup>B</sup>*←*C*←*A*(*ϕ*)+(1−*uind <sup>B</sup>*←*D*←*A*(*ϕ*))*uind <sup>B</sup>*←*C*←*A*(*ϕ*)*dind <sup>B</sup>*←*D*←*A*(*ϕ*) (1−*uind <sup>B</sup>*←*C*←*A*(*ϕ*))*uind <sup>B</sup>*←*D*←*A*(*ϕ*)+(1−*uind <sup>B</sup>*←*D*←*A*)(*ϕ*)*uind <sup>B</sup>*←*C*←*A*(*ϕ*) *uind <sup>B</sup>*←*A*(*ϕ*) = (1−*uind <sup>B</sup>*←*C*←*A*(*ϕ*))*uind <sup>B</sup>*←*C*←*A*(*ϕ*)*uind <sup>B</sup>*←*D*←*A*(*ϕ*)+(1−*uind <sup>B</sup>*←*D*←*A*(*ϕ*))*uind <sup>B</sup>*←*C*←*A*(*ϕ*)*uind <sup>B</sup>*←*D*←*A*(*ϕ*) (1−*uind <sup>B</sup>*←*C*←*A*(*ϕ*))*uind <sup>B</sup>*←*D*←*A*(*ϕ*)+(1−*uind <sup>B</sup>*←*D*←*A*(*ϕ*))*uind <sup>B</sup>*←*C*←*A*(*ϕ*) *aind <sup>B</sup>*←*A*(*ϕ*) = (1−*uind <sup>B</sup>*←*C*←*A*(*ϕ*))*aind <sup>B</sup>*←*C*←*A*(*ϕ*)+(1−*uind <sup>B</sup>*←*D*←*A*(*ϕ*))*aind <sup>B</sup>*←*D*←*A*(*ϕ*) (1−*uind <sup>B</sup>*←*C*←*A*(*ϕ*))+(1−*uind <sup>B</sup>*←*D*←*A*(*ϕ*)) (24)

Therefore, we have the indirect trust calculation function

$$\begin{array}{lcl} f\_{\operatorname{ind}} \left( \overrightarrow{T}\_{\operatorname{B}\leftarrow\operatorname{C}}^{\operatorname{rc}}(\operatorname{\boldsymbol{\mathcal{q}}}), \overrightarrow{T}\_{\operatorname{B}\leftarrow\operatorname{D}}^{\operatorname{\mathtt{rcc}}}(\operatorname{\boldsymbol{\mathcal{q}}}) \right) =\\ \left( \overrightarrow{T}\_{\operatorname{B}\leftarrow\operatorname{C}}^{\operatorname{\mathtt{rcc}}}(\operatorname{\boldsymbol{\mathcal{q}}}) \otimes \overrightarrow{T}\_{\operatorname{C}\leftarrow\operatorname{A}}^{\operatorname{d}}(\operatorname{\boldsymbol{\mathcal{q}}}) \right) \oplus \left( \overrightarrow{T}\_{\operatorname{B}\leftarrow\operatorname{D}}^{\operatorname{\mathtt{rcc}}}(\operatorname{\boldsymbol{\mathcal{q}}}) \otimes \overrightarrow{T}\_{\operatorname{D}\leftarrow\operatorname{A}}^{\operatorname{\mathtt{d}}}(\operatorname{\boldsymbol{\mathcal{q}}}) \right). \end{array} \tag{25}$$

#### 3.1.4. Compositive Trust

The compositive trust is the fusion of direct trust and indirect trust. We also use the consensus operator to fuse them. From Equations (3) and (25), we have

$$\begin{split} \overline{T}\_{B \gets A}^{\sharp}(\boldsymbol{\varrho}) &= f\_{\boldsymbol{\varepsilon}}(\overline{T}\_{B \gets A}^{\mathsf{d}}(\boldsymbol{\varrho}), \overline{T}\_{B \gets A}^{\mathsf{rec}}(\boldsymbol{\varrho}), \overline{T}\_{B \gets D}^{\mathsf{rec}}(\boldsymbol{\varrho})) \\ &= \overline{T}\_{B \gets A}^{\mathsf{d}}(\boldsymbol{\varrho}) \oplus \overline{T}\_{B \gets A}^{\mathsf{ind}}(\boldsymbol{\varrho}) \\ &= \overline{T}\_{B \gets A}^{\mathsf{d}}(\boldsymbol{\varrho}) \oplus [(\overline{T}\_{B \gets C}^{\mathsf{rec}}(\boldsymbol{\varrho}) \otimes \overline{T}\_{C \gets A}^{\mathsf{d}}(\boldsymbol{\varrho})) \oplus (\overline{T}\_{B \gets D}^{\mathsf{rec}}(\boldsymbol{\varrho}) \otimes \overline{T}\_{D \gets A}^{\mathsf{d}}(\boldsymbol{\varrho}))]. \end{split} \tag{26}$$

Therefore, *problem 2* is addressed through the above design and analysis.

#### *3.2. Service Delegation Mechanism*

After calculating the trust vector of the SP *vj* based on the method proposed at last subsection, we further study the issue of service delegation. In SIoT, the SR *ui* will not only consider the trust of the SP *vj*, but also concern the utility. Therefore, we present the trust-based service delegation method to solve the *Problem 3*. We define the decision function of service delegation as follows:

$$\begin{split} \mathcal{U}\_{\mathbb{D}\_{\mathbb{M}} \leftarrow \mathsf{u}\_{i}}(\boldsymbol{\varrho}) &= f\_{\mathsf{lu}}(\overrightarrow{\boldsymbol{T}}\_{\mathbb{D}\_{\mathbb{M}} \leftarrow \mathsf{u}\_{i}}(\boldsymbol{\varrho}), \boldsymbol{\varrho}\_{\mathbb{D}\_{\mathbb{M}}}(\boldsymbol{\varrho})) \\ &= \widehat{\mathsf{T}}\_{\mathbb{D}\_{\mathbb{M}} \leftarrow \mathsf{u}\_{i}}(\boldsymbol{\varrho}) (\zeta\_{\mathsf{u}\_{i}}(\boldsymbol{\varrho}) - \boldsymbol{\varrho}\_{\mathsf{u}\_{i}}(\boldsymbol{\varrho})) + (d\_{\mathsf{u}\_{\mathbb{M}} \leftarrow \mathsf{u}\_{i}}(\boldsymbol{\varrho}) + (1 - a\_{\mathsf{u}\_{\mathbb{M}} \leftarrow \mathsf{u}\_{i}}(\boldsymbol{\varrho})) u\_{\mathsf{u}\_{\mathbb{M}} \leftarrow \mathsf{u}\_{i}}) (-\mathsf{T}\_{\mathsf{u}\_{i}}(\boldsymbol{\varrho})), \end{split} \tag{27}$$

where *ψvj* (*ϕ*) denotes the benefit value when the task is successful and *ζui* (*ϕ*) denotes the lost value when the task is failed. Therefore, the decision of the service delegation (e.g., Equation (4)) can be rewritten as follows:

*DSP* = arg max *vj Uvj*←*ui* (*ϕ*) *s*.*t*. *T*ˆ *vj*←*ui* (*ϕ*)) ≥ *thu*(*ϕ*) (28)

Through the proposed decision-making method for service delegation, the SR can make a plan to maximize its own utility under the consideration of trust of SPs. For the entire SIoT system, on the one hand, our proposed method can guarantee a high task success rate based on trust analysis. On the other hand, we can improve the overall social welfare and boost the cooperation.

#### **4. Simulation and Results**

In order to verify the validity of the subjective logic-based trust model proposed in this section, this study conducts experiments based on the Netlogo experimental platform [37]. NetLogo is an agent-based programming language, which is useful to simulate the interaction among objects and monitor the state changes in a simulative SIoT environment. The construction of the experimental platform is based on our previous work [38]. The trust evaluation mechanism module and service delegation module are adjusted based on the aforementioned bidirectional model. The experiments are divided into the following parts: First, after the interactive experiment, the results of the bidirectional trust evaluation of SPs to SR and SR to SPs are observed to test the effectiveness of subjective logic in the process of trust evaluation. On this basis, the impact of similarity of the services/tasks and positive evaluation rates on trust evaluation results are analyzed. Then, the influence of the number of recommenders on the compositive trust evaluation results is analyzed, and finally the benefits of SR and the changes in the number of responding SPs are measured.

This study defines the rate of positive evidence (RPE) as the proportion of the number of simulated service results that are rated as "positive—that is, satisfied" in the total number of service evaluations. Similarity, the rate of task similarity (RTS) is the similarity of the attributes among the services. For example, when the similarity is 40%, it means that 40% attributes of randomly generated services in the network are consistent. In this experiment, a total of 110 virtual nodes are deployed for service interaction, of which 10 nodes are employed as SRs and 100 nodes are employed as SPs. At the same time, the above virtual nodes will also serve as intermediate nodes in the process of trust evaluation to provide recommendations.

#### *4.1. Comparison of SR and SPs' Basic Bidirectional Trust Evaluation Results*

In this part of the experiment, the positive evaluation rate is set to 50%, and the task similarity is 40%. The experiment runs 500 ticks, and one service/task is executed in each tick. In addition, 10 SPs and 1 SR were randomly selected for observation. Figure 5a,b shows the trust evaluation results of 10 SPs and SR. As shown in Figure 5a, compared with the direct trust evaluation results of each SP, the compositive trust evaluation results for SR have less difference and more comprehensive opinions, which reflects that the evaluation method based on subjective logic can better integrate the recommendations from different sources so that most SPs can have a more consistent evaluation for SR. Similarly, as shown in Figure 5b, after the SR obtains the recommendations of other intermediate nodes in the network, it obtains the integrated evaluation results of each SP's trust. It can be seen that the recommendations of other intermediate nodes will facilitate the SR to make a more accurate evaluation on the trustworthiness of SPs.

**Figure 5.** Bidirectional trust evaluation of SR and SPs.

#### *4.2. The Influence of RPE and RTS on the Results of Trust Evaluation*

This part of the experiment analyzes the impact of RPE and RTS on the evaluation of SR's trust. As shown in Figure 6a, with the increase in the positive evaluation rate, the trust evaluation result of the object will be improved to a certain extent. However, this improvement still has certain limitations. The evaluation results of some SPs for SR may decrease with the increase in RPE. The main reason is that due to the low similarity of tasks. Although some service evaluation opinions are positive or satisfactory, the evidence strength is slight.

**Figure 6.** Trust evaluation of SR with different RPE and RTS.

As shown in Figure 6b, compared with the case where the task similarity is 40%, when the task similarity is 80%, the attributes between tasks are more similar. Therefore, the evidence strength of a single evidence will be increased, which will make the formation of the trust evaluation more accurate and reliable. Compared with Figure 6a, the upper and lower boundaries in Figure 6b are larger, and the differences among different RPE groups are more obvious. It can be demonstrated that when the task similarity is greater, the object can provide more accurate recommendations, thereby forming a more accurate trust evaluation result.

#### *4.3. The Influence of the Number of Recommenders on the Trust Evaluation*

In the process of trust evaluation for a certain SP, the SR needs to collect the recommendation opinions from the intermediate nodes to form a more accurate trust point of view. As shown in Figure 7, when the number of the recommenders is 0, it indicates that the trust value of SP to form the viewpoint of the SR is completely evaluated based on direct experience. Along with the number of recommenders gradually increasing, the SR

can collect more recommendation opinions. From the experimental results of this group, it can be seen that when the number of recommendation opinions is equal to or greater than 6, the SR's trust evaluation opinion on SP tends to be stable, and the SR can more accurately identify the honest and trustworthy SP while avoiding wrongly delegating malicious or negative SPs. Therefore, in order to better evaluate the trustworthiness of the SP, the SR needs to obtain as many recommendations from intermediate nodes as possible during the service delegation process.

**Figure 7.** Trust evaluation of the SP with different number of intermediate nodes.

#### *4.4. Quantity of Responsive SPs and Benefit Analysis of the SR under the Bidirectional Trust Evaluation*

Figure 8 shows the number of responsive SPs and benefits of the SR when the RPE is from 10% to 90% for a certain task. It can be seen that when the RPE is less than 0.5 and the RTS is large, there are more negative opinions referenced. Therefore, the trust evaluation result of SR from the viewpoint of SPs is generally low, and few SPs respond. Therefore, the SR cannot select a suitable SP, and the income is low. With the increase in RPE, the trustworthiness of the SR increases and the number of responding SPs gradually increases, so the SR can obtain a better delegation scheme, which improves the overall revenue. In addition, in the case of small RPE, although the expected benefit of SR is higher when the RTS is lower (the reason is that some SPs cannot correctly estimate the trustworthiness of SR, resulting in a wrong response to the service), it may lead to lower service quality of SPs and failure to guarantee the benefits of SPs. Higher RTS will lead to more accurate bidirectional evaluation results, and more SPs choose not to respond to the service request when RPE is low. On the other hand, in the case of higher RPE, higher RTS will make the bidirectional evaluation between SPs and SR more accurate, so the overall benefit of the SR will be higher.

(**a**) The number of responsive SPs with different RPE. (**b**) Expected utility of the SR with different RPE.

**Figure 8.** The number of responsive SPs and the SR's utility with different RPE.

#### **5. Conclusions and Discussions**

In this article, we studied the trust-based service delegation problem in SIoT. Considering the bidirectionality of trust, we design a framework of the trust model and service delegation. On this basis, we propose a bidirectional trust evaluation method based on subjective logic. We have shown that by using this formulation, the SR and SP can quantitatively evaluate the trust of each other in a reasonable way. In addition, we consider the context of the task to ensure the feasibility of our model in the SIoT scenario. The task similarity and time window are presented for the calculation of evidence strength. The convergence operators including discounting and consensus operator are constructed for compositive trust quantification. The decision-making approach of the service delegation with comprehensive consideration of trust and utility is proposed to ensure the success of the task while improving the utility of the SR.

However, the current work is in infancy. First, considering the computational complexity, the proposed model simplifies the condition setting to a certain extent. The evidence composition in evidence space only includes service attributes, bidirectional service evaluation information, service time, etc., without considering the relationships between device characteristics of IoT objects and service properties. Therefore, our proposed model is more suitable for the scenarios where the degree of heterogeneity and differentiation of IoT devices is low. The evidence-based descriptions of the characteristics of IoT devices and the relationship between these evidence-based descriptions and opinions will be our important future work. Second, with the development of the Internet of Things, some new architectures, such as multiple internets of things, are proposed. Therefore, we will further evaluate whether our model can be feasible and adaptive for various paradigms [39–41]. Moreover, we plan to extend this model and configure a real-world application scenario in order to make it more capable. The task simulations at different network scales will be carried out in the following research process to validate the effectiveness and practicability of our trust model and service delegation method. Furthermore, testing under different attack environments will be also further provided.

**Author Contributions:** Conceptualization, L.W., C.L. and Y.-B.L.; Methodology, L.W. and J.W.; Software, L.W. and Y.Y.; Validation, L.W., Y.Y., J.W., C.L. and Y.-B.L.; Formal Analysis, L.W. and C.L.; Investigation, L.W., Y.Y. and J.W.; Writing—original Draft Preparation, L.W., Y.Y. and Y.-B.L.; Writing—review and Editing, L.W., J.W. and Y.-B.L.; Supervision, C.L. All authors have read and agreed to the published version of the manuscript.

**Funding:** This work was supported by the National Natural Science Foundation of China under Grants 62136006, 62073215 and 61873166.

**Data Availability Statement:** Not applicable.

**Conflicts of Interest:** The authors declare no conflict of interest.

#### **References**


## *Article* **Query Processing in Blockchain Systems: Current State and Future Challenges**

**Dennis Przytarski 1,\*, Christoph Stach 1, Clémentine Gritti <sup>2</sup> and Bernhard Mitschang <sup>1</sup>**


**Abstract:** When, in 2008, Satoshi Nakamoto envisioned the first distributed database management system that relied on cryptographically secured chain of blocks to store data in an immutable and tamper-resistant manner, his primary use case was the introduction of a digital currency. Owing to this use case, the blockchain system was geared towards efficient storage of data, whereas the processing of complex queries, such as provenance analyses of data history, is out of focus. The increasing use of Internet of Things technologies and the resulting digitization in many domains, however, have led to a plethora of novel use cases for a secure digital ledger. For instance, in the healthcare sector, blockchain systems are used for the secure storage and sharing of electronic health records, while the food industry applies such systems to enable a reliable food-chain traceability, e.g., to prove compliance with cold chains. In these application domains, however, querying the current state is not sufficient—comprehensive history queries are required instead. Due to these altered usage modes involving more complex query types, it is questionable whether today's blockchain systems are prepared for this type of usage and whether such queries can be processed efficiently by them. In our paper, we therefore investigate novel use cases for blockchain systems and elicit their requirements towards a data store in terms of query capabilities. We reflect the state of the art in terms of query support in blockchain systems and assess whether it is capable of meeting the requirements of such more sophisticated use cases. As a result, we identify future research challenges with regard to query processing in blockchain systems.

**Keywords:** blockchain systems; query processing; data models; data structures; block structures

#### **1. Introduction**

Digitization fostered by the evolution of the Internet of Things (IoT) has made data one of the most important commodity in both business and private environments [1]. Data became the backbone for a variety of new data-driven application areas such as digital health [2], food supply chain [3], or the production of goods in Industry 4.0 [4]. All of these use cases have in common that they are permanently dependent on demand-driven data provisioning—i.e., the data generated and provided by several data producers must be made available to all data consumers in the required quality and quantity [5]. For this purpose, database systems are often used, as they significantly facilitate the management and provision of data [6].

However, due to the fact that data are nowadays highly valuable, they became attractive targets for cybercriminals who exploit these data in order to harm the involved parties. There is a wide variety of attack types, e.g., tampering with the data in these databases [7]. Detecting data tampering is nearly impossible without additional security measures, consequently being one of the most serious attacks to defend. Considering the worst-case scenario, where data are minimally tampered with, at stages that hardly arouse

**Citation:** Przytarski, D.; Stach, C.; Gritti, C.; Mitschang, B. Query Processing in Blockchain Systems: Current State and Future Challenges. *Future Internet* **2022**, *14*, 1. http:// doi.org/10.3390/fi14010001

Academic Editor: Luis Javier Garcia Villalba

Received: 17 November 2021 Accepted: 13 December 2021 Published: 21 December 2021

**Publisher's Note:** MDPI stays neutral with regard to jurisdictional claims in published maps and institutional affiliations.

**Copyright:** © 2021 by the authors. Licensee MDPI, Basel, Switzerland. This article is an open access article distributed under the terms and conditions of the Creative Commons Attribution (CC BY) license (https:// creativecommons.org/licenses/by/ 4.0/).

suspicion, can cause long-lasting damage to an organization [8]. These attacks are usually performed either by outsiders such as hackers, who are unaffiliated with the organization itself, or by malicious insiders such as untrustworthy database or system administrators. In traditional database systems, data are unprotected against this attack vector because they lack the necessary data integrity checks in the sense of ensuring that stored data are still in the same state as it was once inserted. Therefore, the recent emphasis lies on hardening these databases against data tampering [9].

Another problem is that attackers do not even have to attack the data itself to harm the involved parties. It is already enough to attempt to affect the availability of the data [10]. Denial-of-service attacks cause the database or the server on which it is running to become unreachable by flooding it with fake requests. While the server is occupied with processing the malicious requests, there are no more resources available for processing the legitimate requests, which is why they do not receive any feedback and thus, the data are no longer available to them. Another focus with regard to cybersecurity is, therefore, on strengthening availability to be prepared for the failure of resources [11].

Blockchains offer a solution to these two problems. Firstly, it is immutable and tamperresistant, thus protected against data tampering. Secondly, it is decentralized and thus protected against denial-of-service attacks [12]. Yet, when Satoshi Nakamoto envisioned the first blockchain system for his digital currency *Bitcoin* [13], his priority was to solve the double spending problem, since there is no actual physical relinquishment in a digital currency. Therefore, many of the conveniences of traditional data management systems, such as a powerful query engine, are missing, i.e., they are much less convenient to use in terms of query language and query processing [14].

In this context, blockchains in particular offer many interesting additional use cases for queries due to their internal data management. In a blockchain, data are only appended, which results in the construction of a data log (i.e., blockchain data history) where different revisions of data coexist. This enables the possibility to query the data history for provenance analyses, unlike with a traditional database where data are modified in-place, which means that there is no natively existing data log to query [15]. The existence of this blockchain data history, however, means that applications are forced to store data externally to a blockchain and in many cases also need to perform additional query processing mostly local to the application.

This is why we investigate the necessary query capabilities for blockchain data histories. To this end, we provide three contributions in this paper:


By means of these three contributions, we identify open research gaps that need to be solved in order to enable efficient query processing in blockchain systems.

The remainder of this paper is structured as follows: We open by outlining the fundamentals of blockchain technologies in Section 2, with respect to their relevance in the context of this paper. In particular, our goal is to highlight the conceptual and architectural differences between blockchains and traditional database systems that are responsible for the challenges regarding efficient query processing. We then identify five emerging application domains in Section 3 where blockchains are becoming prevalent for data management. Based on a literature review, we identify types of data and queries that are relevant in these application domains. In Section 4, we generalize these types of data into two object types that must be distinguished when querying blockchains. Then, in Section 5, we determine for these two object types which query capabilities are required in blockchains to be efficiently usable in the application domains. In Section 6, we present the state of the art in research and discuss to which extent it provides these required query

capabilities. Subsequently, we identify future research challenges in Section 7 and conclude this paper in Section 8.

#### **2. Fundamentals of Blockchain Technology**

Before we can delve into queries to a blockchain system, we need to address a few fundamentals of blockchain technology that have an impact on query processing. Even though it is often referred to as "the blockchain", a blockchain is actually a modular assembly of different components. In general terms, a blockchain is a ledger of sequential blocks that contain arbitrary information. This ledger is managed by a network of computers. That is, the distinctive feature of the blockchain is not what can be done with it—i.e., the secure management of data—but rather how this can be accomplished in a decentralized manner on a trustless infrastructure. For this purpose, well-established technologies from different fields of information technology are used in a blockchain. A blockchain architecture therefore has a modular structure, consisting of at least three layers: ➊ Storage, ➋ Network, and ➌ Consensus. Each layer is freely configurable to the respective requirements from a variety of technology variants, with all their advantages and disadvantages [16]. Figure 1 shows this modular architecture. In the following, we discuss these layers in detail.

**Figure 1.** Simplified architecture of a blockchain system with its three layers: ➊ Storage, ➋ Network, and ➌ Consensus.

A blockchain is a list of blocks that are singly linked backwards using cryptographic signatures, with each block containing data. Backward linking is accomplished by including a header in a block that contains the hash value of its predecessor in addition to the actual payload data. A block cannot be modified subsequently, i.e., it is immutable. In particular, data and even entire blocks cannot be deleted retroactively due to this structure. In other words, a blockchain is an append-only data store. When new data are to be added to the blockchain, a new block must be created for this purpose, which is then appended to an existing blockchain [17].

There are many ways to manage a blockchain ➊. Usually, the data in a block are stored in a data structure that enables efficient verification of its integrity (e.g., *Merkle trees* [18], *Modified Merkle Patricia trees* [19]), and the blocks themselves are stored as a log-like structure on a storage device, with derived information stored in a state database for ease of access. The log is therefore mainly used to rebuild or verify the state database in case of problems [20].

Since data are never deleted from a blockchain, a blockchain automatically maintains a native data history. In contrast, a traditional database system must either manually implement the data history at the application layer (e.g., by implementing triggers to populate an audit trail table) or utilize specialized features like plugins for data history support (e.g., *Oracle Flashback Technology* (see https://www.oracle.com/database/technologies/ high-availability/flashback.html; accessed on 15 December 2021) for *Oracle Databases* (see https://www.oracle.com/database/; accessed on 15 December 2021)) [21].

A blockchain is represented by multiple blockchain instances hosted on separate nodes in a distributed manner ➋. This replication approach increases availability and reliability [22].

In order to add new data to a blockchain, a new block must be created and announced to all nodes to become part of all blockchain instances. This distribution feature, however, leads to the possible situation where there could be competing blocks that are linked to the same predecessor and therefore cannot both be appended to the blockchain. To solve this, all nodes have agreed on a consensus mechanism ➌. This ensures that the network agrees on the next state of the blockchain, i.e., which block will be appended next to the blockchain. The consensus mechanism also defines, if a blockchain is permissionless or public, i.e., everyone can maintain a node, or if a blockchain is permissioned or private, i.e., only invited entities can maintain a node [23].

**Permissionless.** Consensus is typically achieved through communication (e.g., voting quorums). In a permissionless blockchain, however, the participants are unknown, so it is not even known how many are participating at all. Here, communication is replaced by computation. It requires that enough work has been put into the creation of a new block so that it can be appended to a permissionless blockchain, e.g., *Proof-of-Work* [24]. This ensures that only one participant generates a new block in a given period of time on average.

**Permissioned.** In a permissioned blockchain, the participants are known, and their number may be limited so that consensus can be reached through communication. This type of consensus is more lightweight and efficient. In most cases, participants do not trust each other, so a central database system as an alternative solution is not an option.

In summary, a blockchain has the following three key properties:


Although blockchains are becoming more and more popular as a secure and trusted data store, they differ significantly from traditional databases because of their completely different focus. While traditional databases are based on client-server architectures, blockchains are managed by a network of peer nodes, each of which holds a redundant copy of the full blockchain data. By eliminating the central management entity that has full control over the data store (and thus the data), trust is built—even if there is no trust among the participants of the network—but the management and communication overhead increases significantly. Besides this transparency, blockchains also create additional trust due to the immutability of the data and their tamper-resistance. These two properties are inherently guaranteed by the design of the blockchain, i.e., by organizing the data into blocks, all of which are linked via the cryptographic hashes in their headers. These blocks have no semantic meaning—they only reflect the chronological sequence in which the data are inserted into the blockchain. Data within a block can be entirely heterogeneous. There is no partitioning of the data into semantically associated tables or a strict schema for describing the data, as is the case for traditional databases. Meanwhile, traditional databases do not have comparable inherent security mechanisms. Yet, these security features are obtained in blockchains by the fact that they are append-only data stores, i.e., data cannot be subsequently deleted or modified. An update to an existing data record must be realized as a new entry, e.g., as a newer version of the complete data record or as an addition entry containing only the changes. As a result, blockchains cannot provide full CRUD

support (create, read, update, and delete). However, due to the append-only structure of blockchains, they provide a complete data history in addition to the current state of the stored data, whereas traditional databases usually only contain the latest snapshot of the data. Depending on the chosen consensus mechanism, it may take some time until a data record is actually included in the blockchain, whereas there is no such delay in traditional database systems [25,26]. For all these conceptual and architectural reasons, query performance is also much higher for traditional databases in terms of throughput, the key efficiency metric for data stores [27,28]. Table 1 summarizes the main differences between traditional databases and blockchains that have an impact on their query capabilities.


**Table 1.** Main differences between traditional databases and blockchains.

Unlike in traditional database systems, data do not necessarily have to be stored in a blockchain. To this end, there are basically two approaches [29]. In the first approach called "on-chain", the actual data are stored within a blockchain. In the second approach, called "off-chain", the actual data are still stored in a traditional database system, but the information required to verify the actual data is stored on the blockchain. However, the verification overhead is significantly greater than with the first approach. Hybrid approaches are also possible, e.g., data are stored partly in a blockchain and partly in a traditional database system with their verification information on a blockchain.

Overall, the public verification of the data in a blockchain is a fundamental characteristic of blockchain technology. This transparency enables every node to check the integrity of the data in a blockchain, thus creating trust in the stored data. The focus on blockchain technology is on security, unlike traditional database systems, which focus on performance (i.e., transaction throughput). Additionally, blockchain technology provides protection

against attackers, whether from hackers or malicious insiders, as well as protection against a single point of failure or attack, as data are replicated by many nodes, hopefully located around the world.

#### **3. Application Domains Identified through Literature Review**

As shown in the previous section, blockchains are technically very different from traditional databases, yet blockchains can in principle be used just like traditional databases—as a data store. Due to their decentralization, immutability, and tamper-resistance, blockchains offer additional security features that traditional data stores lack. At the time of this writing, many entities like companies, governments, and startups are evaluating the applicability of blockchain technology in their domains. As a result, further use cases utilizing blockchain technology in addition to a cryptocurrency have emerged over the course of time. According to Lo et al. [30], the use of blockchain technology is particularly beneficial when one or more of the following requirements are present:


From our literature review, we have identified five main application domains where one or more of the aforementioned requirements are present, and blockchain technology could therefore be a suitable technical design choice. These domains are *health data management* (see Section 3.1), *financial accounting* (see Section 3.2), *registries* (see Section 3.3), *food supply chains* (see Section 3.4), and *e-voting* (see Section 3.5). From these application domains, we derive typical types of data and types of queries in order to determine whether today's blockchain technology provides comprehensive query capabilities of the data history of a blockchain. These application domains are just a few selected examples that seemed particularly relevant in the context of our work. There are many other application domains that have similar query requirements, e.g., in the domains of *Smart Grids* [31,32], *digital rights management* [33,34], or *Smart Traffic* [35,36].

The main findings regarding the requirements for the query engine resulting from these use cases are summarized at the end of this section (see Section 3.6).

#### *3.1. Health Data Management*

In the health sector, digitization of many processes can significantly facilitate the lives of patients and physicians [37]. To this end, data in the form of patient records, e.g., electronic health records [38], must be shared and extended reliably and trustworthy among physicians. For example, a primary care physician prepares a medical record, and then refers the patient to a specialist, who adds their diagnosis. In addition, due to the *Quantified Self Movement* [39], people started to monitor themselves using IoT technologies, e.g., blood glucose measurements via continuous glucose monitoring [40] or heart rates via a smartwatch [41]. All these measured data are gathered in a central hub (e.g., a smartphone) and linked to compose a personal health profile [42]. By adding these personal health profiles to the patient records, physicians have access to even more health-related data which helps them to make a more accurate diagnosis.

The use of blockchain technology is suitable in such a use case because it allows decentralized data sharing. With a blockchain, a hospital can provide a data infrastructure through which physicians can share patient data with each other in a simple manner [43]. Moreover, the inherent immutability and tamper-resistance characteristics of a blockchain

ensure data security, which is mandatory for medical data. This is particularly important due to the increasing threat of cyberattacks in healthcare [44]. By enabling patients to participate in the blockchain, they are empowered to provide additional health-related data on their own [45].

Especially when sensitive data such as health data are stored in a blockchain, it is obvious that data privacy protection measures have to be applied. This, however, contradicts the fundamental principles of a blockchain, according to which every participant has full access to all data. To this end, Peng et al. [46] present an approach in which data are stored tamper-resistant in a blockchain, but in which queries are processed in a privacy-preserving manner, and in which the result sets do not allow further inference about the data subjects.

There are multiple examples in literature in which blockchains are used to manage and share health data, e.g., De Aguiar et al. [47], Hasselgren et al. [48], Khatoon [49], Przytarski et al. [50], and Tanwar et al. [51].

Based on this research, we can conclude that there are two types of data in health data management:


In the context of health data management, queries regarding the current health status of an individual patient, information on disease progression over a given period of time, as well as aggregate measurement data are particularly relevant. Typical queries therefore include, but are not limited to:


#### *3.2. Financial Accounting*

Today's accounting is still based on the double-entry system that was described in a treatise written by Luca Pacioli over 500 years ago [52]. The double-entry system has two sides known as debit and credit. Each financial record is entered into an account on both sides where the entry on the credit side is a corresponding and opposite entry of the debit side. The books are considered trustworthy if and only if the sum of the debits equals the sum of the credits [53]. Since a company is accountable to multiple parties—e.g., owners and investors—it is necessary to publish financial statements regularly. This implies that financial data must be shared with these shareholders, but also with tax advisors and financial authorities. The exchange of data is usually carried out via the error-prone import and export functionality of accounting software. As financial records must be immutable by law—i.e., they must not be tampered with retrospectively—such a modus operandi entails a considerable threat potential [54].

Since blockchain technology has already proven to be a backbone for cryptocurrencies, they also seem suitable for financial accounting. Accounts for any kind of assets, liabilities, equity, revenue, and expenses are established [55]. As all transactions between these accounts are transparent to all participants of the blockchain and no party has sole control over the blockchain due to its decentralized and distributed design, it can be considered a trusted single view of truth. Moreover, due to the immutability of financial records, a blockchain-based financial accounting is almost immune to tampering [56].

There are multiple examples in literature in which blockchains are used to support accounting, e.g., Faccia et al. [57], Gökten and Özdo ˘gan [58], Schmitz and Leoni [59], Sveistrup Søgaard [60], and Zhang et al. [61].

Based on this research, we can conclude that there is only one type of data in financial accounting:

• The data entered by companies and tax advisors are financial records that are only valid at a specific point in time.

In the context of financial accounting, queries regarding the aggregated characteristic values over a given period of time or queries that support an accounting report are particularly relevant. Typical queries therefore include, but are not limited to:


#### *3.3. Registries*

A registry is an authoritative data source of records, usually maintained by a government agency. For instance, a land registry specifies who is permitted to use land, for how long, and on which conditions. Although the registry is maintained by a central authority, several other parties have to have access to the data in order to enable an economic and healthy business environment for the sale and purchase of property [62]. Only a few countries maintain a functioning land registry, which is still often based on paper-based documents, leaving them vulnerable to loss, misuse, or corruption. As a result, delays in ownership transfer or tampering with the land register are possible and bound to happen on a regular basis [63]. Another problem is that some registries exist duplicated in siloed entities so that this fragmentation might cause possible data conflicts and therefore, no single view of truth [64].

It is obvious that the use of blockchain technology can also provide a solution to all of these problems. On the one hand, blockchain technology ensures that documents are available to all participants almost immediately after they have been added to the blockchain. This eliminates unnecessary delays in processing that occur when paperbased documents are shipped. As a result, all participants always have the latest state of a document at their disposal and conflicting copies of one and the same document cannot exist [65]. On the other hand, the use of blockchains reliably prevents the forgery of documents due to the characteristics of a blockchain, i.e., its immutability and tamperresistance. Since no central authority can gain full control over the blockchain, corruption is also not a problem as long as the majority of the participants are honest [66]. Obviously, it must be ensured that insights from the documents are not made public. However, this can be achieved by means of access policies and tailored permissions restricting the access of individual parties to the data. Such an approach is acceptable in terms of fraud protection as long as the blockchain itself is still governed by multiple entities [67].

This benefit is also demonstrated by many research papers for other registries, e.g., Benarous et al. [68], Rosado et al. [69], Sahai and Pandey [70], Shinde et al. [71], and Singh Yadav and Singh Kushwaha [72].

Based on this research, we can conclude that there is only one type of data in registries:

• The data entered into registries are usually documents (i.e., semi-structured data) that are modified over time. Typically, the latest state of a document is of importance, but in cases of conflicts, its history is also required (e.g., in court).

In the context of registries, queries regarding the latest of a certain document (as well as its history) are particularly relevant. Moreover, a data subject can be part of multiple registries, e.g., one registry containing all house owners and one containing all vehicle owners. In order to determine all properties of a certain data subject, a join between all available registries is required. Typical queries therefore include, but are not limited to:


#### *3.4. Food Supply Chains*

A supply chain is a network of entities in such sectors as agriculture and manufacturing ranging from producers, who produce a product or service, to the final consumer. In such supply chains, not only the physical exchange of the goods is important, but also the exchange of information about these goods. This information must be available to the participants of supply chain management in order to be able to ensure comprehensive quality control [73]. In the food industry, for example, meat products must maintain a cold chain in order to avoid endangering consumers' health [74]. This means, the temperature of the meat products has to be permanently monitored and fully documented during transport from the slaughterhouse to a retail store [75]. In order to exclude human errors, IoT technologies can be used for the metering and documentation [76].

While the use of IoT technologies can prevent unintentional measurement errors, it is also necessary to prevent tampering with the documents retrospectively, e.g., to guarantee that a breach of the cold chain is recognizable. Although the captured data must not be edited subsequently, it has to be possible to modify the accompanying documents to the meat products nevertheless, e.g., if additional entries are made during customs inspections or when the goods are handed over to the next supply chain entity [77]. The use of a blockchain to establish an immutable and decentralized data store for this data therefore makes sense. Besides eliminating the risk of fraud, the transparent data sharing capabilities of the blockchain also increase consumer confidence in the quality assurance of food products, as they can verify it in a tamper-proof manner [78].

There are multiple examples in literature in which blockchains are used to store proofs and certificates regarding food supply chains, e.g., Duan et al. [79], Köhler and Pizzol [80], Kayikci et al. [81], Shahid et al. [82], and Zhang et al. [83].

Based on this research, we can conclude that there are two types of data in food supply chains:


In the context of food supply chains, queries that provide an aggregated overview of all captured data, as well as comprehensive querying of all documented data related to the transport, are particularly relevant. Typical queries, therefore, include, but are not limited to:


#### *3.5. E-Voting*

Electronic voting systems (known as e-voting) are a means of strengthening democratic processes. By digitizing the election process, not only is bureaucracy reduced, but people can cast their votes much more efficiently. This is an advantage especially for elderly voters or voters with a disability, as e-voting enables them to participate in the election without having to leave home and rely on the help of others [84]. While in the past, mostly technical difficulties impeded the introduction of e-voting, in today's fully connected world, it is rather a matter of security concerns [85]. To this end, the transmission of votes must be trustworthy and secure [86], and the secrecy of the ballot has to be respected [87].

However, one of the most important confidence-building measures is to ensure full transparency in e-voting and election results. This means, all voters must be able to verify that every vote is counted and that ballots are not manipulated retroactively. The use of blockchains is therefore particularly suitable to manage the votes. First of all, the community decides by consensus which data are included in the blockchain, i.e., which votes are

valid. Storing votes in a blockchain ensures that they are immutable, and tampering can be detected immediately. In addition, blockchains provide great transparency because each participant in the blockchain network keeps a complete copy of the blockchain—and thus all of the data—on their node [88]. Furthermore, the decentralized nature of blockchains ensures availability, as they are less susceptible to denial-of-service attacks than a centralized approach [89].

There are multiple examples in literature in which blockchains are used to support secure and transparent e-voting, e.g., Hanifatunnisa and Rahardjo [90], Hjálmarsson et al. [91], Kshetri and Voas [92], Ruparel et al. [93], and Wang et al. [94].

Based on this research, we can conclude that there is only one type of data in e-voting:

• The votes are stored in the blockchain as independent records. Once a vote has been cast, it must not be subsequently altered or deleted. Without any loss of generality, we assume that some kind of verification of whether a ballot is valid takes place before the votes are entered into the blockchain. Therefore, no extensions to the stored data are required.

In the context of e-voting, statistical queries that aggregate the stored data are particularly relevant. Typical queries therefore include, but are not limited to:


#### *3.6. Lessons Learned*

Derived from the presented application domains, we conclude that there are two different types of data that are entered into a blockchain. We outline their characteristics in Table 2. The first type of data entered into a blockchain is only valid at a specific point in time, which we call a *constant object*. Constant objects are, in other words, just events, such as those known from complex event processing [95]. However, there is a peculiarity in dealing with the timestamp of a constant object. This is because the timestamp can be dependent on the block in which the object is stored (i.e., an object with a *block-dependent timestamp*), or dependent on the object, because the object itself provides a timestamp attribute that must be used rather than the timestamp of the block (i.e., an object with an *object-dependent timestamp*). The second type of data entered into a blockchain is modified over time, which we call an *expandable object*. As the modifications are scattered over many blocks, they must first be combined in order to be used further. Therefore, expandable objects have only block-dependent timestamps. We use the term "object" to describe a set of attributes, i.e., data in the form of a set of key-value pairs, so-called fields. Although the concept of objects is mainly known in the paradigm of object orientation, this data model does not restrict us to the use of object-oriented data stores. These objects can also be represented in other data models such as *JSON documents*, *RDF triples* (i.e., mapping the fields of an object to individual triples), or *XML instances*. Listing **??** shows an object named obj1 with three attributes and their values in those three representations. We discuss those object types further in Section 4.

Furthermore, from the presented use cases, we derive eight query capabilities that an efficient query engine for blockchain systems has to support in order to be usable in the given application domains. These required capabilities are *projection*, *selection*, *sorting*, *aggregation*, *grouping*, and *joins*. These operators are well-known from the *relational algebra*, on which the query languages of many traditional database systems are based.


**Table 2.** The two types of objects which are relevant in the context of blockchains.

**Listing 1.** An object with three attributes and their values represented as a JSON document, RDF triples, and an XML instance.


Projection means selecting specific attributes from objects that are included in the result set, i.e., if an object has several attributes, only a specific subset of them is returned. For instance, a physician requires a projection operator to query specifically blood pressure measurements from an electronic health record, which also includes other medical data such as blood glucose measurements or dietary studies. Selection means eliminating objects from the result set, i.e., an object is only included in the result set, if its attribute values meet a given condition. For instance, a physician requires a selection operator to query for female patients (i.e., patients whose attribute "gender" is set to "female"). Sorting means to sort the objects in the result set in ascending or descending order, based on the values of the attributes of the objects. For instance, in financial accounting, it is necessary to sort the accounting items in order to present them according to the date they were registered. Aggregation means to compute a single value from a set of values with the help of an aggregate function, such as average, maximum/minimum, or sum. For instance, in financial accounting, an aggregation is required to compare the total sum of income with the total sum of expenses in the end. Grouping means to partition objects into groups of objects, based on the values of their attribute. For instance, land registries have to group the landowners based on the county their property is assigned to. Usually, an aggregation is then applied on these groups, e.g., to determine how much real estate tax each county receives. Joining means to combine data from multiple sources into a joint result set. While in traditional database systems joins are applied to different tables within the same database, in blockchains there is no such semantically structuring construct like a table. Therefore, joins have to be applied to different blockchains. This, however, raises further technical issues, see Sections 5 and 7. Nevertheless, there are use cases in which joins have to be supported by blockchain systems. For instance, if there are different registries, e.g., a land register and a car register, each stored in its own blockchain. In order to query all possessions of a data subject, a join on all of these blockchains is necessary.

In addition to these six basic query operators, which are also known from traditional database systems, blockchains have special requirements towards query capabilities due to the two different object types that have to be handled by them. Firstly, there are *temporal queries* when dealing with constant objects. In temporal queries, the temporal relationship of the data plays a key role. These time references can be obtained from two different sources: On the one hand, each block has its own inherent timestamp. Since new blocks can only be added at the end of the blockchain, the sequence of the blocks implicitly reflects the chronological order in which they were created. This timestamp is used for block-dependent objects for temporal queries. However, it is possible that this timestamp deviates substantially from the time at which a data object was captured, since data initially remain in a data pool until a consensus is reached, and they are added to a new block. Therefore, for object-dependent objects, where the time of capturing the data is crucial, an additional individual timestamp for each object is needed. For instance, in the e-voting context it is necessary to query only valid votes, i.e., only ballots that were submitted neither too early nor too late have to be considered. Secondly, there are state-based queries when dealing with expandable objects. Such objects are initially added to the blockchain and then changes are made by means of transactions (e.g., to change certain attribute values, and add or remove some attributes) which are also stored in the blockchain. In a state-based query, the complete change history up to a specific point in time must therefore first be retrieved from the blockchain in order to assemble the expandable object. For instance, in the food supply chain it must be possible to query the status of a food product at any time between production and sale, e.g., in order to monitor the cold chain.

Table 3 provides an overview of these six basic operators as well as the two blockchainspecific query capabilities. More details on these query options are provided in Section 5.


**Table 3.** Overview of the six basic query operators (white rows) and two blockchain-specific query capabilities (gray rows) derived from the presented application domains.

#### **4. Object Types in Blockchains**

From the presented application domains in Section 3, we derive two object types that are relevant in the context of blockchains, namely constant objects and expandable objects. Their main properties are summarized in Table 2. In the following, we elaborate on these two object types and describe why they need to be considered in particular when managing data in blockchains.

As described in Section 2, blockchains are append-only data stores where blocks are appended to an existing blockchain. Furthermore, blocks cannot be modified subsequently, so the data within a block are immutable. If changes to the data must occur, there are two options. Either the complete object with all its fields is recreated or only a change history is

kept. This means that there are two different forms of use. Either, an object *lives* until a new version of it is added to the blockchain or the entire change history of an object must be searched in the blockchain and applied to the *genesis object*, i.e., the original version of the object. These two forms of use are reflected by the following two object types:

**Constant Object.** A constant object is final. This means that once the object is added to a block, its fields do not change. Constant objects occur over time and are valid at a specific point in time. In other words, constant objects are events, i.e., actions or occurrences that happened at a specific point in time.

**Expandable Object.** An expandable object is never final. This means that over time, the fields of this object are modified, new fields are added, or existing fields are removed. In other words, expandable objects are documents that get modified over time.

Constant objects are, for example, votes in e-voting (see Figure 2a) or blood pressure measurements from medical IoT devices in health data management (see Figure 2b).

(**a**) Votes during an election, represented as constant objects with block-dependent timestamps, which are aggregated by an election administrator.

(**b**) Blood pressure measurements from medical IoT devices, represented as constant objects with object-dependent timestamps, which are analyzed by a physician.

**Figure 2.** Two different use cases utilizing constant objects with (**a**) block-dependent timestamps and (**b**) object-dependent timestamps.

In e-voting, votes are created by voters during elections. These votes are only valid once they are successfully added to the blockchain. A vote does not contain its own timestamp attribute, because in this case, only the timestamp of the block is relevant. An election official can query and aggregate these votes to derive valuable information about an election. For these queries, it is relevant in which block a vote is included.

In health data management, a medical IoT device performs blood pressure measurements at certain time intervals. These measurements are either added to the blockchain individually or in batches. A measurement contains, among other attributes, a timestamp that records the time of the measurement. A physician can query and aggregate these measurements so that valuable information can be derived for the patient. For these queries, however, it is not relevant in which block the measurement is included, but at which time it was performed (nota bene: Due to the delayed insertion of data into the blockchain, not only the timestamp of a measurement can significantly differ from the timestamp of the block it is stored in, but also the chronological order in which measurements are captured can differ from the order within the blocks.).

Thus, in the first example, the timestamp of the block is relevant, but in the second example, the timestamp of the object is relevant. For this reason, we introduce the following notion for timestamps on objects:

**Block-Dependent.** In this case, the object depends on the timestamp of the block it was included in. Each block has its own timestamp, i.e., the time at which it was created. Here, the timestamp of a block acts as a global timestamp for all its payload data, superseding possible timestamp attributes of objects, thus all objects in a block have the same timestamp. **Object-Dependent.** In this case, the object has its own timestamp attribute. Additionally, it is not relevant in which block this object was included. During query processing, the timestamps of these objects must be considered instead of the timestamp of a block. However, this entails new challenges. In a blockchain architecture, there is no guarantee that the objects are sorted by the timestamp attribute of the objects. As a result, when searching for an object with a specific timestamp, it can only be assumed that the object was created earlier than the block that includes it. Thus, the lower search bound is set by the timestamp of the object, however, no statement can be made about the upper search bound.

Whether an object has a block-dependent or an object-dependent timestamp is determined by its further usage. In our e-voting example, the action is to cast a vote and this is considered to be performed once it is correctly added to the blockchain. In our health data management example, the action is a blood pressure measurement carried out by an IoT medical device, which is considered to be performed once the measurement is successfully completed. This action is completely independent of the creation of a block for a blockchain.

Expandable objects are, for example, documents in land registries (see Figure 3). An expandable object consists of a genesis object (i.e., the source object) as well as modifications to the object that are scattered over numerous blocks. As a result, it has as many states (i.e., document revisions) as how many blocks exist that include fields of this object.

**Figure 3.** A land registry document, represented as expandable object, which is modified over time. Different states of the document can be retrieved, i.e., the latest state and all historical states.

In land registries, land documents are inserted, modified, and deleted over time. When a land document is modified, it means that fields of the document are modified, new fields are added, or existing fields are removed. The result of a modification is a new state of the expandable object. Thus, each block that include a modification of an expandable object represents a different state of this very object. A land registry advisor can query these land documents at any available state. For this, the requested state of the document has to be computed.

To compute a state of an expandable object, all fields from the previous and the requested block must be combined. This is done by recursively recombining the fields from the first block that includes fields of the object until the requested state—this approach is also called *left-folding*.

In our land registry example, the object first appeared in Block 10, the so-called genesis object. After that, there have been two modifications to it, namely in Block 33 and Block 89. This means that there are three states for this object, all of which can be queried. Querying its state in Block 10 is simple, since no modifications have taken place yet. Querying its state in Block 33 requires its assembly by combining the fields from Block 10 with the

modifications in Block 33. The same procedure is used for querying its state in Block 89, although an additional combination step has to be performed then.

Furthermore, the timestamps of expandable objects are only block-dependent, i.e., the block defines the corresponding timestamp for these objects.

#### **5. Query Capabilities for Blockchain Technology**

As discussed in Section 4, the different object types have a significant impact on how data can be queried in a blockchain. Therefore, in this section, we adapt a potential query language to the object types using the query capabilities listed in Table 3 and elaborate on possible issues that need to be considered when implementing a query engine.

In blockchain technology, writing data is a completely different process compared to traditional database systems. This is due to the consensus mechanism used to add new data to the blockchain (see Section 2). Therefore, we only consider non-modifying query techniques, i.e., read queries as they have no persistent effects. Nevertheless, data can still be added to a blockchain by creating a new block that includes the new data and propagating it via the given consensus mechanism.

A query engine consists of a frontend and a backend. The frontend is responsible for transforming a query written in a defined query language into an intermediate representation. The backend is responsible for processing this intermediate representation and computing the result of that query.

The use cases shown in Section 3 require comprehensive query capabilities such as aggregations or joins. For the complete breakdown of required capabilities, see Table 3. We consider a query engine to be powerful, if it supports a query language with at least the same power as a SELECT statement from the declarative query language SQL—just like in traditional database systems. Current blockchain systems, however, have native but naive query interfaces [96]. Moreover, their query languages and the efficiency of query processing is severely limited [97]. Since descriptive query languages have proven themselves in practice also for object-oriented database systems [98], we describe the required queries in SQL. SQL provides an expressive query language [99], however, SQL is just one example that can easily be replaced by any other declarative query language. In particular, we focus on the SELECT statement, since this is used for the read queries. However, the SELECT statement cannot be simply adopted, but has to be modified to support the different object types.

In relational database systems, the SQL SELECT statement is the most common option to query a database. Within this SELECT statement, there are various clauses intended for, e.g., selecting, aggregating, or sorting. Table 4 shows these various clauses and maps them to the respective query capability along with a mapping to the blockchain domain.

For almost all of these clauses, a relatively straightforward mapping to the blockchain domain can be found. However, the JOIN command represents an exception. Since blockchains have no logical internal structuring (nota bene: The blocks in which the data are organized have no semantic meaning regarding the data. They only represent the chronological order in which the data were added to the blockchain.) (e.g., in semantically and schematically homogeneous tables), a JOIN gets a different and new meaning in this context. As illustrated in the example of the registries (see Section 3.3), it happens in practice that data from a single data subject are contained in several different blockchains. To collect and combine all information, a JOIN across multiple blockchains is required. However, as outlined in Section 2, blockchains do not have a uniform structure. Thus, it must be resolved how a JOIN can be realized despite the highly diverse technologies that are involved in this case.

While these SQL clauses are sufficient to cover all six basic query operators (see Table 3), the inclusion of novel blockchain-specific object types (see Section 4) represent a significant deviation from SQL. Due to these object types, additional query capabilities—alongside with extensions to the query language—are needed in blockchain systems.


**Table 4.** The various clauses of an SQL statement and their mapping to the blockchain domain.

Constant objects are self-contained, which means that, considered individually, they do not provide valuable information in most cases. Thus, it is suitable to consider several of these objects at the same time. This can be done, for example, either in the form of an aggregation or viewing the data as time series to track any trends. In order to support this, a start and end point are required. However, the range queries differ here in whether the objects have block-dependent or object-dependent timestamps. For objects with blockdependent timestamps, the timestamp of a block is relevant, therefore, it must be possible to specify two block numbers. Thus, it must be possible to search between block *N*<sup>1</sup> and block *<sup>N</sup>*2. To apply this to SQL, the SELECT start clause could be adjusted as follows:

**Block Range.** SELECT <attributes> BETWEEN BLOCK *<sup>N</sup>*<sup>1</sup> AND *<sup>N</sup>*<sup>2</sup>

(where *<sup>N</sup>*<sup>1</sup> and *<sup>N</sup>*<sup>2</sup> of type Integer and *<sup>N</sup>*<sup>1</sup> <sup>≤</sup> *<sup>N</sup>*2)

A *block range* is necessary when a blockchain stores constant objects with block-dependent timestamps.

The situation is different for objects with object-dependent timestamps. Here, the order in which the data was added to the blockchain is irrelevant, it only matters when the data was originally generated. Therefore, it is necessary to search via the timestamp of the objects. This means that only objects created between timestamp *T*<sup>1</sup> and *T*<sup>2</sup> are searched. To apply this to SQL, the SELECT start clause could be adjusted as follows:

**Timestamp Range.** SELECT <attributes> BETWEEN TIMESTAMP *<sup>T</sup>*<sup>1</sup> AND *<sup>T</sup>*<sup>2</sup> (where *<sup>T</sup>*<sup>1</sup> and *<sup>T</sup>*<sup>2</sup> of type DateTime (e.g., ISO 8601 [100]) and *<sup>T</sup>*<sup>1</sup> <sup>≤</sup> *<sup>T</sup>*2)

A *timestamp range* is necessary when a blockchain stores constant objects with object-dependent timestamps.

Even though the two queries look very similar, they are internally very different from each other. Since the block range corresponds to the structure of the blockchain, such a query can be supported very efficiently. The timestamp range, however, requires all blocks between the block with timestamp *T*<sup>1</sup> (nota bene: Even if it is not clear when an object is added to the blockchain, the insertion time (i.e., the timestamp of a block) can in no case precede the timestamp of the object (i.e., the time of capturing).) and now to be searched, since the timestamp of the actual block where the object has been included is greater than the timestamp of the object itself.

Expandable objects have fields that are scattered over one or more blocks. These objects must be assembled before they can be processed to compute the result of a query. It is obvious that the states of all processed objects must be at the same *height* (In this context, the term "height" is used to describe the block number within a blockchain up to which all required objects have to be assembled.) to prevent the processing of incompatible states of data. Therefore, it is necessary to specify a block number *N* up to which block the objects are being assembled (nota bene: A lower bound is not required in this case, since it is always necessary to start with the genesis object and apply all modifications from there.). To support this, the SELECT start clause could be adjusted as follows:

```
Block Number. SELECT <attributes> ASOF BLOCK N
```
(where *<sup>N</sup>* of type Integer)

A *block number* is necessary when a blockchain stores expandable objects.

This way, all required query capabilities for all object types can be represented in a declarative query language. This shows how powerful a declarative query language is. However, the query language is just the frontend of a query engine.

The actual issues arise when the backend of a query engine is considered, as it accesses the underlying data structures to compute the result of a query. We identified the following eight issues that need to be addressed:


processing, if possible, or as an additional step by verifying an externally computed result against the blockchain?


#### **6. Overview of the State of the Art**

While blockchain technology was initially developed for cryptocurrencies, for which it is sufficient to query the current account balance, the new use cases identified from the application domains in Section 3 introduce different types of objects (see Section 4) that require comprehensive query capabilities (see Section 5). Since there is not a standard for blockchain systems, but rather a modular design that can be freely configured from a variety of technology variants (see Section 2), there are various blockchain systems, each targeting a different goal. As a result, the query capabilities of these systems are quite different. In this section, we therefore first consider the state of technology (see Section 6.1) and then the state of research (see Section 6.2) in the field of query processing in blockchains.

#### *6.1. State of Technology*

The currently most popular blockchain system *Hyperledger Fabric* [101] manages a ledger that consists of a blockchain and a database that holds the current *world state*. The world state represents the latest state of a blockchain and is stored in an additional NoSQL database. Hyperledger Fabric uses *CouchDB* (see https://couchdb.apache.org; accessed on 15 December 2021) to this end. Despite the fact that a blockchain maintains a native data history, however, there are only limited interfaces to access this data history (e.g., through Fabric SDK (see https://hyperledger-fabric.readthedocs.io/en/release-2. 2/fabric-sdks.html; accessed on 15 December 2021) or smart contracts). It is possible to execute comprehensive queries against the CouchDB, which manages the latest state. However, the result of a query is not cross-checked against the blockchain, so there is a possibility of reading tampered data.

In such blockchain systems, there is no efficient technique to query the underlying data structure, i.e., the data history of the blockchain. A solution to overcome this limitation is therefore to duplicate the data of the blockchain (or even just the current state) into a separate database with support for a powerful query engine, while sacrificing the built-in technique of the blockchain to verify the integrity of data while computing the result of a query. If, thus, information must be directly extracted from the data history

of the blockchain, expert knowledge and self-developed tools are required to extract this information.

Furthermore, there are systems that have features from blockchains and databases. They are called hybrid systems and there are two alternative approaches. The first approach is to start with a blockchain system and then enhance it with database features. The second approach is to start with a database system and then enhance it with blockchain features. Ruan et al. [102] compare six of such hybrid systems and came to the following findings:

**Blockchain Systems Enhanced with Database Features.** These systems use blockchains as an integrity-protected data store and utilize a separate database layer on top of it. Within the network, storage operations are replicated (e.g., a block containing transactions) rather than individual transactions. Examples are:


**Database Systems Enhanced with Blockchain Features.** These systems use ordinary database systems and utilize transaction-based replication. Within the network, each node manages its own database instance and executes globally ordered transactions (achieved through a consensus mechanism) on it. Examples are:


We conclude that in both approaches, the system *can* provide query capabilities that are mostly as powerful as the query engines of the applied database systems (i.e., document-oriented databases and relational databases). However, these underlying traditional database systems provide no support for block range queries, timestamp range queries, and block number queries, as required in modern blockchain use cases. In addition, each approach has its own disadvantage.

The disadvantage of blockchain systems enhanced with database features is generally that data in the database are decoupled from the data in the blockchain so that verifying the results of a query is an additional step that can become expensive. Depending on how the data of the blockchain are stored in the database, queries are possible either only on the latest state or also on the history. FalconDB uses *MySQL* (see https://www.mysql.com ; accessed on 15 December 2021), which provides a relational data model, that they extended by temporal attributes to support SQL queries on the history.

The disadvantage of database systems enhanced with blockchain features is generally that the database system itself might not use tamper-resistant data structures so that tampered data is detectable. There are techniques to overcome this such as querying multiple nodes in the blockchain network and comparing the result or re-executing the transactions from the blockchain to detect incorrect data. However, these techniques are cumbersome and can also become expensive.

#### *6.2. State of Research*

Given the problems with the State of Technology, there is also a variety of research. These can be divided into four research directions:

**Improvements to the Frontend Query Capabilities.** *Ethereum* [110] is a popular public blockchain that supports smart contracts, which are programs with code (i.e., functions) and data (i.e., states) that run on the blockchain. It uses the key-value database LevelDB as persistent storage. Han et al. [111] extend the Ethereum-based blockchain system *quorum* by an embedded relational database system *SQLite* (see https://www.sqlite.org/index.html; accessed on 15 December 2021) next to *LevelDB* (see https://github.com/google/leveldb; accessed on 15 December 2021) enabling SQL SELECT queries. In this system, the data of smart contract transactions are stored in the SQLite database instead of the LevelDB database. Smart contract transactions can use SQL queries (e.g., range or conditional queries), which are then executed by the relational database system. However, there are some open questions, e.g.,


The research work of Tong et al. [112] also focuses on providing SQL support in blockchains systems. However, they take a different approach. They introduce an SQL middleware, which encapsulates RPC-based (remote procedure call) interfaces of blockchain systems as SQL interfaces to facilitate SQL queries on the blockchain data, just like the aforementioned approach, where blockchain systems are enhanced with database features. Furthermore, Li et al. [113] present a data query layer called *EtherQL*, which enables a set of useful analytical queries such as range and top-k queries on the blockchain Ethereum.

**Efficiency Improvements in Query Processing.** Bragagnolo et al. [114] use the parallelization technique Map/Reduce to extract and analyze information from a blockchain, in their case from the Ethereum blockchain. Here, a master node instructs different jobs to worker nodes, each of which extracts data from the Ethereum blockchain and writes them to a relational database. After that, queries can be made to the relational database to obtain information from the Ethereum blockchain.

Xu et al. [115] present an accumulator-based authenticated data structure that allows aggregation over arbitrary attributes. This enables lightweight users, i.e., users who have only the block headers locally stored, to have service providers storing the full blockchain to execute boolean range queries, while allowing them to verify the integrity of the results.

Xing et al. [116] present a subchain index structure for the transaction chain. Here, the transaction chain is divided into subchains and different subchains are linked with hash pointers. The goal is to shorten the query path for queries on historical transactions.

Jia et al. [117] present the *AB-M tree* structure as a storage structure for transactions, which combines the advantages of *balanced binary trees* (fast data retrieval) and Merkle trees (fast data verification). Instead of storing transactions in an ordinary Merkle tree within a block, they are now stored in an AB-M tree. This provides faster transaction retrieval, but at the same time guarantees the integrity of the transactions.

Peng et al. [118] and, based on this, Wu et al. [119] present a middleware layer called *Verifiable Query Layer* (*VQL*). It extracts information about the blocks, their transactions, and possible balances from an underlying blockchain system and stores these data reorganized in one or more databases so that queries can be answered more efficiently. Then, a cryptographic hash value for each generated database is computed and stored in a blockchain, preferably in the underlying blockchain system. Whenever data is queried

through the middle layer, the integrity of the queried database can be verified by comparing the hash value in the blockchain with the hash value computed by the user.

**Tailored Blockchain Optimizations for Specific Use Cases.** As IoT technologies capture growing volumes of time series data, there is an emerging need to comprehensively analyze it in an efficient manner. While there are approaches to verify the authenticity of the sources of this IoT data [120] and subsequently provide these time series data to third parties on a demand-driven basis [121], it is also necessary to ensure that the data cannot be tampered with when it is stored and managed.

Wortner et al. [122] therefore investigate particularly for time series data how these can be managed in blockchain systems and how in particular their timestamps, which play a key role in subsequent analyses, can be protected against tampering. In this context, however, the focus is solely on the storage of the data. An efficient processing of queries or let alone an analysis of the blockchain data is completely out of scope. This is being researched by Dhanush et al. [123]. In their approach, however, the time series data must first be completely extracted from the blockchain and then stored and analyzed in a special time series database (e.g., *InfluxDB* (see https://www.influxdata.com/products/influxdb/; accessed on 15 December 2021)) for which there are tailored analysis tools and dashboards (e.g., *Grafana* (see https://grafana.com; accessed on 15 December 2021)). This causes a large overhead, because there are no efficient ways to restrict the amount of data in such a way that only those data are read that are relevant for the analysis. Since the amount of data in the blockchain is continuously growing due to the append-only nature of the blockchain, this overhead is also constantly increasing. Another problem with this approach is the fact that once the data has been extracted, there is no longer any protection against tampering. This completely undermines the main reason why the data was stored in the blockchain in the first place.

Yu et al. [124] therefore propose a novel blockchain storage architecture specifically for time series data. In their approach, they introduce an index structure for blockchains enabling an efficient access to the blocks and transactions in conjunction with a time series database for managing the time series data. The system decides for incoming queries whether they should be processed by the blockchain or the time series data and then forwards them accordingly. This approach reduces the overhead significantly, because on the one hand, time series databases are highly optimized to process time series queries. On the other hand, time series data are not immutable so that the data volume can be reduced as needed by deleting data that is no longer needed. However, this also represents the key weak point of this approach—the data in the time series databases are not protected against tampering or deletion.

Yet, there are research approaches towards tailored index structures especially for time series data in blockchains. Studies show that the performance of time series queries in blockchain systems can be increased significantly by such indices [125]. This could also improve the throughput of, for example, timestamp range queries (see Section 5).

Similar research approaches can be found for other specialized data and query types, such as index structures for location data in order to support efficient spatial queries, e.g., the work by Nurgaliev et al. [126].

**Verifiable Queries and Database Systems.** With verifiable queries, a user is able to verify the integrity of the result of a query. This ensures that the data and the execution have not been tampered with. For this purpose, a new class of database systems has emerged, the so-called verifiable database systems.

Zhang et al. [127] propose such a verifiable database system called *vSQL*, which supports arbitrary SQL queries. Here, a user is able to outsource a relational database to an untrusted server and has only to store a hash value locally. Then, the user can send SQL queries to that untrusted server and verify the integrity of the result. This verification is done by an interactive protocol, which utilizes interactive proofs.

Zhang et al. [128] propose another verifiable database system, which is called *Spitz*. It builds on top of *Forkbase* [129], which is a distributed multi-version storage engine utilizing the key-value data model, and maintains multiple index structures to facilitate verifiable query processing. The verification of the result of a query is done by comparing the hash value, which must be computed by using the proofs included in the result, with a previously locally stored hash value.

Zhou et al. [130] propose an SGX-based verifiable database system called *VeriDB*, which uses a trusted execution environment called *Intel SGX* (see https://www.intel.com/content/ www/us/en/architecture-and-technology/software-guard-extensions.html; accessed on 15 December 2021) where data are isolated and encrypted in memory [131]. VeriDB hosts the query engine supporting SQL queries within an Intel SGX enclave, with the actual data residing in untrusted memory. The verification of the data is performed during the query processing by the query engine using a verifiable storage layer.

Table 5 summarizes the main findings regarding the characteristics and features of these six research directions in the field of query processing in blockchains.


**Table 5.** Summary of key findings regarding the state of the art.

Blockchains were conceptually not developed to compete with traditional database systems in terms of data and query throughput. However, due to their inherent security features, they are increasingly used for managing important data. Considering the current state of technology, however, blockchains are still at the very beginning as far as query capabilities are concerned. Either one has to live with the native but naive query interfaces or the data processing takes place in a connected database system, which partially eliminates or at least reduces the security features. Therefore, there is a large body of research that aims to improve query capabilities in terms of usability, power, and performance. However, as our assessment of the state of research has shown, there are still many open

research questions to be answered. In the following section, we elaborate on these open research questions.

#### **7. Future Research Challenges**

In this section, we elaborate on future research challenges based on the issues identified in Section 5 that need to be solved in order to enable an efficient query processing in blockchain systems. We group these issues into four categories of challenges, namely research challenges regarding *data models*, *data structures*, *block structures*, and *query processing*.

#### *7.1. Data Models*

In order to realize a JOIN operator for blockchains, a query engine has to be able to access, read, and process the common data stock of all involved blockchain systems. Since different blockchain systems have a highly heterogeneous technological infrastructure, a generic and standardized data model is needed that can be applied on all of these systems (see Issue A). Furthermore, for constant objects with object-dependent timestamps, it is useful to assign these timestamps a special status in the data model in order to access them more easily and in a standardized manner. To enable comparability of objects, it is worth considering introducing a type system, so that it is ensured that when comparing attributes of multiple objects with the same identifier, they are of the same type (see Issue B). Therefore, the first challenge is to create a standard for an expressive data model for blockchains. With such a data model, it must be possible to represent arbitrary kinds of data for any given use case. Triples, for example, have demonstrated their suitability in the context of RDF stores and could also be a beneficial approach for a blockchain data model.

#### *7.2. Data Structures*

In order to process queries on blockchain systems efficiently, state-of-the-art solutions operate a traditional database system in parallel to the actual blockchain. This database presents the current world state, i.e., the current value of the attributes of the objects stored in the blockchain. However, since these database systems cannot check the integrity of the data as required, an additional verification step is needed to check the results against the blockchain (see Issue C). To eliminate this verification step, it is necessary to come up with novel data structures, e.g., by combining search data structures with authenticated data structures such as *Merkle B-Trees* [132]. Such data structures are applied in current blockchain systems such as Ethereum. However, these structures are primarily used to facilitate the verification of transactions. A full-fledged support for comprehensive queries, as required by emerging use cases, is not provided by these structures. Therefore, the second challenge is to investigate how data structures can be designed that store generic data in a verifiable manner while providing fast access to the stored data.

#### *7.3. Block Structures*

There is some flexibility in organizing the data within a block. Data can either be physically clustered or added to useful data structures that allow efficient access to that data (see Issue D). It is also possible to construct index structures outside a block, but this would again require an additional verification step to check the results of a query against the blockchain. Thus, it is necessary to consider how the data are stored within a block. For example, different versions of the data can be stored within a block, each optimized for a certain type of query [133], similar to a triplestore with an *RDF3X engine* [134]. A lot of related work is concerned with the support of efficient spatio-temporal queries by adding special index structures to blockchain systems. Similar efforts are also needed for other types of data that are relevant in emerging application domains for blockchains (see Issue E). For example, expandable objects require special index structures in order to assemble them more efficiently. This can be done by storing pointers to their previous state, which simplifies left-folding. Similarly, constant objects also require index structures so that their

history can be queried efficiently. Therefore, the third challenge is to investigate how the structure of a block could be designed to efficiently support different types of queries.

#### *7.4. Query Processing*

In query processing, the question is whether technically both object types (constant and expandable) can be supported at the same time (see Issue F). Even if this is technically possible, it could be contradictory from the perspective of the query language. The same question arises whether constant objects with object-dependent timestamps should be stored together with block-dependent timestamps (see Issue G). Another difficulty concerns the expandable objects, since their fields might be scattered over multiple blocks (see Issue H). During query processing, it is first necessary to locate the blocks that include the fields of the requested object, and then to assemble them by left-folding. Therefore, the fourth challenge is to investigate how query processing should be performed for each object type in order to efficiently compute the result of a query. Additionally, it is also necessary to investigate how a user can be supported in such a way that they can adequately formulate their queries.

The four research challenges mentioned above generally apply to any current blockchain system due to the conceptual design of blockchains. However, we expect that two factors will make these challenges even more difficult in the future, namely new blockchain architectures and legal restrictions.

#### *7.5. New Blockchain Architectures*

The fundamental architecture of a blockchain, as presented in Section 2, is constantly evolving. One trend that can be observed in this context is the so-called *sharding*. Sharding is introduced to address the typically low scalability of blockchains [135]. With blockchain sharding, the blockchain data is horizontally partitioned into shards where each shard is managed by a subset of the nodes in a network. One strategy in this regard can be to keep thematically related data in a common partition in order to create homogeneous partitions. A quite similar approach is known from traditional databases when a *snowflake schema* is applied. That is, data is divided among several tables in accordance with a specific dimension [136]. This makes queries regarding a certain topic highly efficient, since only a part of the data needs to be processed. However, the number of necessary joins increases if a comprehensive view on the entire data set is required. The same issue arises with sharding. As discussed in Issue A, blockchain systems are not designed to support joins efficiently. Moreover, the nodes that belong to an associated shard can only validate data they store. Therefore, when a join is made, the validation results from different shards must first be merged. For this reason, the data structures and block structures as well as the query processing must be adapted so that even complex JOIN operators can be executed efficiently.

Another emerging trend are the so-called *atomic cross-chain swaps*. Here, multiple parties exchange assets across multiple blockchains. Initially, this function was introduced so that different cryptocurrencies can be traded [137]. However, the exchanged assets are technically not limited to cryptocurrencies. That is, using cross-chain swaps, it is also possible to transfer data from one blockchain system to another [138]. Similar to sharding, this allows to create thematically homogeneous blockchains. Each blockchain provider would then only include data that corresponds to its respective topic. If necessary, external content can be imported from another blockchain via cross-chain swaps. Of course, this also results in the same challenges as with sharding, namely the high number of joins required to obtain a comprehensive view on the entire data set. Unlike sharding, where all partitions have at least the same technical foundation, cross-chain swap requires a wide variety of blockchain systems to interoperate in order to support cross-chain join operations. Thus, the data structures and block structures must also be created in a cross-blockchain manner.

#### *7.6. Legal Restrictions*

As illustrated in Section 3.1, blockchains are becoming increasingly popular for storing sensitive data, such as health data. However, such private data are protected by data protection laws, such as the *General Data Protection Regulation (GDPR)* [139]. Although blockchains are ideal for the secure storage and distribution of sensitive data in terms of immutability and tamper-resistance, they are fundamentally in conflict with data privacy principles [140]. Special categories of personal data, such as health data, however, are subject to a particularly high degree of protection—here data subjects must be granted full control over their data. To this end, comprehensive adjustments to a blockchain are necessary [141]. In particular, the *right to be forgotten* is in conflict with the immutability of a blockchain, and the *right to restriction of processing* contradicts the fully decentralized distribution of data to nodes that manage them autonomously. Moreover, it is impossible for data subjects to exercise their right to data minimization against individual data processors, since the data are tamper-resistant available in a blockchain [142].

However, such adjustments to make a blockchain GDPR-compliant also have a significant impact on query processing in blockchains. These implications concern two aspects in particular. On the one hand, due to the right to be forgotten DELETE statements are required. In the context of blockchains, however, this is technically difficult not only due to immutability, but also because of expandable objects. If such an object has to be deleted, initially all components of the object have to be found. These components can be distributed arbitrarily over all blocks of the blockchain. To support DELETE statements efficiently, data structures and block structures are required that exceed auxiliary structures found in current blockchains systems significantly. On the other hand, the access control in blockchain systems must be considerably refined in order to grant data subjects the legally guaranteed control over their data. Data subjects must be able to make fine-grained decisions about who should have access to which data. As a consequence, queries regarding the change history of objects become much more complex in particular. If a user has restricted access to some of the changes, only, it must be resolved how a history query can be executed in this case without having to process the restricted data. Expandable objects constitute a special challenge in this respect as well, since they can only be queried and assembled if all components can be accessed. If this cannot be guaranteed due to access restrictions, the data models and also the query processing itself have to be revised.

#### **8. Conclusions**

Blockchains are considered the new go-to technology in many application domains to store data in an immutable and tamper-resistant manner while ensuring high availability. A blockchain, however, is rather a conceptual design than a specific embodiment of a technology. Therefore, there are different implementations of a blockchain, each with their respective advantages and disadvantages. To support query capabilities on blockchain data, there are currently two prevalent approaches:

The first approach is to store all data in the blockchain and then execute the queries on it. The advantages of this approach are that the data history is fully available, and the data are protected by being immutable and tamper-resistant. The disadvantage of this approach is that query processing requires sequential traversal of the blocks, since there are no index structures to improve the efficiency of query processing.

The second approach is to operate a database in parallel to the blockchain. This database maintains the world state. This way, SQL-like queries can be executed efficiently, which is this approach's advantage. Its disadvantage is that such a database does not provide the data history. As a consequence, temporal queries and state-based queries are not or at least insufficiently supported. Furthermore, the authenticity of this data is not guaranteed by the blockchain. To this end, an additional verification step is required.

Therefore, to unlock the full potential of the blockchain technology (i.e., security and data history combined with comprehensive query capabilities), many research efforts are still needed (e.g., in terms of developing new index and data access structures for blockchains). In particular, we identified four categories of current research challenges in this regard: data models, data structures, block structures, and query processing.

In summary, the importance of blockchain systems as a secure data store is undeniable for a digitized society. However, there are still many research questions to be addressed before blockchains can compete with traditional database systems in terms of query capabilities and efficiency.

**Author Contributions:** Conceptualization, C.G., D.P. and C.S.; methodology, D.P. and C.S.; software, D.P.; validation, C.G., D.P. and C.S.; formal analysis, D.P. and C.S.; investigation, D.P. and C.S.; resources, B.M.; data curation, D.P. and C.S.; writing—original draft preparation, D.P. and C.S.; writing—review and editing, C.G., B.M., D.P. and C.S.; visualization, D.P. and C.S.; supervision, B.M. and C.S.; project administration, B.M. and D.P.; funding acquisition, B.M. All authors have read and agreed to the published version of the manuscript.

**Funding:** This research was funded by German Federal Ministry of Education and Research (BMBF) as part of the Software Campus program grant number 01IS17051.

**Institutional Review Board Statement:** Not applicable.

**Informed Consent Statement:** Not applicable.

**Data Availability Statement:** Not applicable.

**Acknowledgments:** We thank the anonymous reviewers for their valuable comments and suggestions which helped us to improve the content and presentation of this paper.

**Conflicts of Interest:** The authors declare no conflict of interest.

#### **References**


## *Article* **Enable Fair Proof-of-Work (PoW) Consensus for Blockchains in IoT by Miner Twins (MinT)**

**Qian Qu 1, Ronghua Xu 1, Yu Chen 1,\*, Erik Blasch <sup>2</sup> and Alexander Aved <sup>2</sup>**


**Abstract:** Blockchain technology has been recognized as a promising solution to enhance the security and privacy of Internet of Things (IoT) and Edge Computing scenarios. Taking advantage of the Proofof-Work (PoW) consensus protocol, which solves a computation intensive hashing puzzle, Blockchain ensures the security of the system by establishing a digital ledger. However, the computation intensive PoW favors members possessing more computing power. In the IoT paradigm, fairness in the highly heterogeneous network edge environments must consider devices with various constraints on computation power. Inspired by the advanced features of Digital Twins (DT), an emerging concept that mirrors the lifespan and operational characteristics of physical objects, we propose a novel Miner Twins (MinT) architecture to enable a fair PoW consensus mechanism for blockchains in IoT environments. MinT adopts an edge-fog-cloud hierarchy. All physical miners of the blockchain are deployed as microservices on distributed edge devices, while fog/cloud servers maintain digital twins that periodically update miners' running status. By timely monitoring of a miner's footprint that is mirrored by twins, a lightweight Singular Spectrum Analysis (SSA)-based detection achieves the identification of individual misbehaved miners that violate fair mining. Moreover, we also design a novel Proof-of-Behavior (PoB) consensus algorithm to detect dishonest miners that collude to control a fair mining network. A preliminary study is conducted on a proof-of-concept prototype implementation, and experimental evaluation shows the feasibility and effectiveness of the proposed MinT scheme under a distributed byzantine network environment.

**Keywords:** digital twin; blockchain; Proof-of-Work; microservices; Singular Spectrum Analysis (SSA); byzantine fault tolerance

#### **1. Introduction**

Advancement in Internet of Things (IoT), Edge Computing, Big Data (BD), and Artificial Intelligence (AI)/Machine Learning (ML) technologies makes the concept of Smart Cities realistic. However, widely adopting IoT-based applications and services in smart cities also brings new security and privacy concerns. Thanks to multiple attractive features including decentralization, auditability and traceability, blockchain has been widely recognized as a great potential to revolutionize the fundamentals of information and communication technology (ICT) [1]. Applying blockchain to smart cities is promising to bring efficiency, scalability and security properties to IoT-based applications, such as smart surveillance [2], privacy preservation [3], decentralized data marketplaces [4], time banking of community [5], identity authentication [6] and access control [7,8].

Digital Twins (DT) is being developed to optimize manufacturing and aviation processes [9]. By monitoring, simulating and mirroring the status of a physical object (PO), DT can build an intelligent and evolving system model based on the logic object (LO). Leveraging data fusion and AI/ML algorithms, DT can be used to predict the behavior of the PO given some specific situations or environments. Similar to DT, the Dynamic Data

**Citation:** Qu, Q.; Xu, R.; Chen, Y.; Blasch, E.; Aved, A. Enable Fair Proof-of-Work (PoW) Consensus for Blockchains in IoT by Miner Twins (MinT). *Future Internet* **2021**, *13*, 291. https://doi.org/10.3390/fi13110291

Academic Editor: Christoph Stach

Received: 30 October 2021 Accepted: 16 November 2021 Published: 19 November 2021

**Publisher's Note:** MDPI stays neutral with regard to jurisdictional claims in published maps and institutional affiliations.

**Copyright:** © 2021 by the authors. Licensee MDPI, Basel, Switzerland. This article is an open access article distributed under the terms and conditions of the Creative Commons Attribution (CC BY) license (https:// creativecommons.org/licenses/by/ 4.0/).

Driven Applications Systems (DDDAS) concept developed in the late 1990s seeks to use modeling to support predictive expectations based on the coordination with models and data [10]. Thus, DDDAS can determine optimized solutions or even failure preventive actions on POs to enable an intelligent and resilient system.

Research has been conducted to apply blockchain to enable many attractive features in DTs, including transparency, decentralization, data immutability and Peer-to-Peer (P2P) communication [11]. However, directly integrating existing blockchain technologies into the highly heterogeneous IoT environments presents critical challenges in terms of scalability, performance, security and fairness [12]. Some permissioned blockchains use a Practical Byzantine Fault Tolerance (PBFT) [13] protocol, which demonstrates high throughput and low latency but only allows for a very limited network scalability in terms of the number of validators. Most permissionless blockchain networks utilize a hashing-intensive Proof-of-Work (PoW) consensus protocol to achieve security and scalability guarantees. Due to the various computation capability of miners, mining centralization in a PoW blockchain not only leads to inequity of rewarding among participants but also brings about security issues, such as majority (51%) attacks [14].

Inspired by the essential features of DTs, mirroring and monitoring, this paper proposes a novel edge-fog-cloud Miner Twins (MinT) architecture to enable a fair PoW consensus mechanism for blockchains in IoT environments. In the MinT architecture, the fog/cloud sever establishes and maintains digital twins for the miners of the blockchain, which are deployed as microservices in edge devices that participate in the blockchain network. Container technology is adopted to encapsulate PoW algorithm as microservices, and each containerized miner is dedicated to mining tasks using pre-configured computation power. As each miner has the same constrained computation resources, it becomes affordable to optimize resource limited IoT devices.

In summary, this paper makes the following contributions:


The remainder of this paper is organized as follows: Section 2 reviews the background on blockchain and PoW consensus and then briefly discusses the state-of-the-art research on DT. Section 3 introduces the rationale and architecture of MinT. The miner twin-enabled fair-mining mechanism including SSA and PoB-based detection algorithms is explained in Section 4.1. Section 5 presents the prototype implementation with numerical results. Section 6 concludes the paper with future work.

#### **2. Related Work**

This section introduces blockchain and PoW consensus background knowledge. Following that, we describe digital twin technology and how DT can be used to guarantee the fair mining scheme in blockchain.

#### *2.1. Blockchain and Nakamoto Consensus Protocol*

As a form of distributed ledger technology (DLT), *Blockchain* was initially implemented as an enabling technology of Bitcoin [15], which aimed to provide a cryptocurrency to record and verify commercial transactions among trustless entities in a decentralized manner. With the decentralized P2P network architecture and cryptographic mechanisms, participants in a blockchain system maintain the immutability and auditability of data and transactions recorded on the distributed ledger instead of relying on a centralized third party trust authority.

As one of the most fundamental problems in a distributed/decentralized computing environment, *consensus* in a blockchain network can be defined as a fault-tolerant statemachine replication problem, which aims to maintain the globally distributed ledger state across the P2P network. Bitcoin adopts the Nakamoto consensus based on a Proof-of-Work (PoW) scheme to achieve pseudonymity, scalability and probabilistic finality in an asynchronous and open-access network environment. The goal of Nakamoto consensus is to ensure all participants agree on a common network transaction log as a serialized blockchain [12].

PoW is essentially an incentive-based consensus algorithm, which requires all participants to compete for rewards through a cryptographic block discovery racing game. To be a winner in PoW block generation, every miner has to solve a computing-intensive hash puzzle problem. In brief, a valid PoW solution requires exhaustively querying a cryptographic hash function for a partial preimage generated from a candidate block [16]. Finally, the hash code of a candidate block must satisfy a predefined difficulty condition parameter *h*, such as having a fixed length of bits as zeros.

Given current *block*\_*data*, which consists of a block header and ordered transactions by time stamps, a miner continually calculates a hash value *nonce* until it satisfies the PoW puzzle problem. The PoW puzzle problem can be formally defined as follows:

$$hash\\_block = \mathcal{H}(block\\_data|name) \lessapprox D(h),\tag{1}$$

where for some fixed length of bits *<sup>L</sup>* and difficulty condition, *<sup>D</sup>*(*h*) = <sup>2</sup>*L*−*h*. H(·) is a predefined collision-resistant cryptographic hash function that outputs a hash string *<sup>L</sup>* ∈ {0, 1}*λ*, and *<sup>λ</sup>* is the length of a hash string.

The PoW process defined by Equation (1) is essentially a verifiable process of a weighted random coin-tossing [12]. Thus, the probability of generating a valid block is in proportion to miners' computation resources. Higher computation power leads to higher hash string rate in PoW, which means more rewards and benefits. Such a mining centralization may discourage participants who have limited computation resources, such as IoT devices; but it also lead to majority (51%) attacks if an adversary controls more than 50% of the computation resources of the whole network.

To reduce energy consumption in PoW consensus, Peercoin [17] proposed Proofof-Stake (PoS), which requires a miner to use its coin stake to solve the puzzle solution. Unlike PoW protocols that relies on a brute-force hash calculation, PoS miners use a process of "virtual mining" manner that only consumes limited computational resources. However, PoS still has a mining centralization issue because an attacker can amplify its power by simply accumulating the credit stake. As the first practical Byzantine Fault Tolerant (BFT) consensus, Practical BFT (PBFT) [13] guarantees both liveness and safety in synchronous network environments given the assumption that at most of  *<sup>n</sup>*−<sup>1</sup> <sup>3</sup> out of total of *n* participants in consensus protocol are Byzantine faults. As PBFT requires that all nodes communicate synchronously to achieve consensus purposes, it has poor scalability due to high latency and communication overhead as more nodes join the consensus network.

#### *2.2. Digital Twins*

The concept of DT was proposed in 2002 and archived in a NASA white paper in 2014 [18]. Essentially, a DT is a digital representation of the components and dynamics of a physical system [19]. Based on the functionalities, DTs can be roughly categorized into three kinds: monitoring DTs, simulational DTs and operational DTs [20]. As suggested by the names, monitoring twins allow system operators to monitor the status of a physical system; simulation twins can predict the future status of the physical system in different scenarios using various simulation tools and ML algorithms; and operational twins is a *complex sensing and control system* that enabled human operators to interact with a cyberphysical system and to perform different actions in addition to monitoring, analysis and prediction [21], which is similar to human–machine teaming [22].

Earlier studies on DT mainly focused on the area of manufacturing covering different key factors for smart manufacturing including simulation, optimization and the use of AI. For instance, an event-driven simulation for manufacturing and assembly tasks based on Digital Twin and human–robot collaboration was presented [23]. A DT-based framework was proposed to achieve high precision and multidisciplinary coupling during the assembly process, which mainly focused on High precision products (HPPs) workshops [24]. HPP also establishes a predict and optimization model as well as a case study to verify the effectiveness and feasibility. A case study presented an ice cream machine as an application example of DT in food industry [25], which focused on the visualization and interaction based on virtual reality (VR) and augmented reality (AR) technologies. Secure data transmission was also highlighted in the framework by employing a secure gate between machine and cloud.

Recently, efforts are reported in variant aspects of smart cities including Smart Driving, Smart Grid and Smart Healthcare. For instance, the optimization issue in the electric propulsion drive systems (EPDS) of self-driving electric vehicles were discussed [26]. In the proposed DT-based framework, the connection between a logical twin in the control software with the propulsion motor drive system enables EPDS performance estimation. However, there were no experimental results presented after giving the concepts of the platform. A behaviors-based algorithm was proposed to help the drivers avoid potential risk [27]. Combining the ML techniques and DT relies on the connectivity of the system and faces challenges in optimization and accuracy [28]. A case study has been reported that tackles the management of wind farm using DT and cloud technologies combined with big data analysis to build remote control station [29].

Recently, some healthcare applications redefined DT by including living objects [30]. A DT-based healthcare framework was proposed for monitoring and predicting the health condition of an individual using wearable devices [31]. A DT-based remote surgery prototype was introduced consisting of VR, 4G and AI to create a digital twin of a patient and to realize real-time surgery over mobile network [32]. Due to the fast development of telecommunication technologies, 5G and beyond networks are very complicated as they are expected to support more emerging applications with more diverse requirements [33]. The community is considering DT as an efficient, cost-effective approach to accelerate the design, test and implementation of 5G/6G networks [34].

Due to the foreseeable importance and popularity of DT in IoT, 5G/6G and edge computing, blockchain is adopted to enhance the security, trust and reliability of DTs [11,35]. The work reported in this paper, however, is the first in this area that leverages DT to tackle the unfair mining problem in the PoW consensus protocol. Using digital twins, MinT monitors the computing resource utility of the miners and quickly detects abusers using Singular Spectrum Analysis (SSA) [36], one of the fastest change point detection algorithms [37]. Our MinT also uses a Proof-of-Behavior (PoB) consensus algorithm to guarantee byzantine tolerant anomaly detection.

#### **3. MinT: Rationale and Architecture**

Aiming at a secure-by-design fair PoW mining network in heterogeneous IoT environments, our MinT scheme leverages DT technology to continuously monitor the usage of containerized miners and discourages misbehaving nodes from unfairly overwhelming the peers by using extra computing power. Figure 1 illustrates the high-level system architecture of MinT, which adopts a hierarchical cloud-fog-edge computing paradigm. Such a hierarchical framework not only provides system scalability for large-scale fair mining tasks based on geographically distributed IoT devices but also supports flexible management and coordinated central and decentralized local decisions given heterogeneous networks

and application domains. Moreover, MinT relies on a permissioned network that provides basic security guarantees, such as the public key infrastructure (PKI) and digital signature, data integrity [2], identity authentication [6] and access control [38], etc. In essential, MinT is a partial decentralized PoW mining network. Furthermore, DTs in MinT are mainly used to monitor their associated miners and to support misbehavior detection, and they do not directly participate in the PoW mining task or impose interference on the consensus protocol. Therefore, our Mint is promising in enabling a fair mining network without sacrificing distribution and decentralization. The rationale behind the MinT is described as follows:

**Figure 1.** Illustration of MinT system architecture.

**1. Containerized PoW Miner**: The edge layer in MinT consists of various types of IoT devices, such as smart cameras in a surveillance system or smart meters connected to a power grid. To follow an ideal "one cup-one vote" Nakamoto consensus protocol, the Pow algorithm is encapsulated into containers as physical miners that are deployed on edge devices to participate in the blockchain network, and all containers are assigned the same computation resource for PoW mining process. Each miner has the same probability of generating blocks and being rewarded accordingly due to the uniform computation distribution of the network. Thus, these containerized PoW miners construct a fair mining blockchain network disregarding devices' capability.

**2. Microservice-oriented Service**: MinT utilizes an intermediate fog layer to provide middle-ware services for devices at edge and cloud level. To address heterogeneity of IoT systems, a lightweight Microservice-oriented architecture (MoA) is adopted as a fundamental service infrastructure to support functionality, such as data aggregation and microservice management, and security mechanisms, such as encryption/decryption; to identity verification; to access control, etc. Each microservice unit exposes a set of RESTful web-service APIs for interaction. The fine-granularity and loose-coupling features of the MoA framework allow for fast development and easy deployment among heterogeneous platforms using non-standard development.

**3. DT-enabled Fair Mining Intelligence**: As dishonest containerized miners could use extra computing power than they are permitted, MinT relies on DT technology and intelligent services on a fog/cloud server to maintain a fair mining network at the edge layer. By aggregating data flows from distributed physical miners, mirroring miners (logic objects) that are associated with their physical counterparts are created and managed by the fog or cloud server. These miner twins monitor the usage of containerized miners running on devices. By analyzing the real-time status of miner twins and historical statistics, abusers can be detected and preventive actions can be triggered to deter identified misbehaving miners such that the MinT ensures a fair mining blockchain network.

#### **4. Miner Twin-Enabled Fair-Mining Mechanism**

This section provides a comprehensive overview of the MinT-based fair mining mechanism such that readers can understand the key components and workflow. Then, we describe the miner twin process including key parameter selection. Following that, we offer details on lightweight SSA-based anomaly detection and the byzantine tolerant PoB consensus algorithm.

#### *4.1. MinT Workflow for Fair Mining*

Figure 2 illustrates the workflow of the fair-mining mechanism in the MinT system. The upstream data flow starts from the containerized miners and aggregates the fog servers installed with different modules. The fog server first normalize the data from all physical miners, which reports to it under its jurisdiction. The fog server can either construct logical miners that mirror these new physical miners or update the status of existing logical miners. The fog server further encrypts its local logical twining miners and forwards them to the cloud.

**Figure 2.** Miner twin-based fair-mining flowchart.

Upon receiving the encrypted data from multiple fog servers, the cloud server aggregates the information into a logical miners pool to represent a system level twinning PoW network. Using the live feed from the logical twin and the historical data, MinT uses an intelligent model for fair mining strategy. Given a fair mining algorithm, the upstream data flow starts from the predication. The predicted status is compared with the actual footprint, using anomaly detection algorithm MinT; identifies dishonest miners who violate the fair PoW consensus; and sends orders to the Microservice Control Module on a fog layer accordingly, which takes further actions on the "outlaws".

#### *4.2. Miner Twin Process*

The notations used in this paper are listed in Table 1. To mirror the physical miner, several parameters are extracted for the logical miner, including central CPU usage (*C*), global GPU usage (*G*), memory usage (*M*) and I/O bandwidth (*B*). Since PoW depends on computation intensive algorithms, the CPU usage and GPU usage are chosen as the key parameters according to the selection of calculation module, while memory, I/O bandwidth and other metrics are considered as contributing parameters. To avoid falling behind other miners, the physical miner normally uses all of the allocated CPU/GPU resources.

As the system resource allocated to each miner is restricted but identical, the data can be normalized in the form of percentages, for example *c* = *<sup>C</sup> Cset* × 100%, where *Cset* is the preset CPU limit and *c* is the normalized value. Given an assumption that a containerized miner can only use its CPU to perform the PoW algorithm, then for a miner *k*, the parameter vector of its Physical Object (physical miner) with timestamp *i* would be *POki* = (*cki*, *gki*, *mki*, *bki*), and the Key Parameter is *cki*. The vector for the Logical Object (logic miner) can be represented as *LOki* = (*cki*, *gki*, *mki*, *bki*), and the Key Parameter is *cki*.

**Table 1.** Relevant basic notations.


#### *4.3. Fast Anomaly Detection for Fair Mining*

Fast and accurate identification of the misbehaved miners is an essential step to ensuring fair mining, where MinT adopts the Singular Spectrum Analysis (SSA) algorithm to achieve this goal. SSA is recognized as one of the quickest sequential change-point detection approaches for processing time series problems [39]. By decomposing and reconstructing the interested time series, SSA extracts certain components of the origin series such as periodic pattern, noises, trends, etc. SSA is widely used in solving problems such as smoothing, extraction of seasonality components, as well as study the structure in some minor time series and change-point detection [36].

Unlike traditional methods, SSA is non-parametric and does not require prior knowledge of the parametric model of the considered time series data. Although SSA uses some statistical concepts, it does not need any statistical assumptions about the target series. Moreover, SSA algorithm can be used for processing time series with relatively small size, which make this method more suitable for edge-fog scenarios [40]. The SSA algorithm can be divided into four steps as (see Moskvina et al. at 2003) [41]:

**1. Embedding:** The target of SSA is a one-dimensional time series X = [*x*1, ..., *xN*], where *N* is the series length. By choosing proper window length *L*, one can transfer the times series into multi-dimensional series of vectors *X <sup>i</sup>*. Combine these vectors results in the trajectory matrix *X* = [*X*-1, *X*-2, ..., *X*-*<sup>K</sup>*], where *K* = *N* − *L* + 1. The multi-dimensional vectors *X <sup>i</sup>* = (*xi*, . . ., *xL*+*i*−1) , *i* = 1, . . ., *K*, are also called lagged vectors.

**2. Singular Value Decomposition (SVD) [42]:** After singular value decomposing the trajectory matrix *X*, the eigenvalues are denoted by *λ*1, ..., *λ<sup>L</sup>* in decreasing order of magnitude and the corresponding eigenvectors *U*1, ..., *UL* where the matrix *U* = [*U*1, *U*2..., *UL*] and **Ui** = 1 is orthogonal. Then, the eigentriples are ( <sup>√</sup>*λi*, *Ui*, *Vi*), by denoting *Vi* = *X Ui*/ <sup>√</sup>*λi*. Supposing that the rank of *<sup>X</sup>* is *<sup>d</sup>*, then the trajectory matrix is *X* = *X*<sup>1</sup> + ... + *Xd*.

**3. Grouping and Reconstructing:** The next step is to group the matrices *Xi* into certain groups and to calculate the sum within these groups. Therefore, we denote a subset indices *I* = *i*1, *i*2, . . ., *il*, where *l* < *L*. Therefore, the corresponding matrix is *XI* = *Xi*<sup>1</sup> + ... + *Xil* .

**4. Diagonal Averaging:** Using diagonal averaging, we can transfer *XI* into time series X*I*.

$$\mathbb{X}\_{I}(i) = \begin{cases} \frac{1}{i} \sum\_{j=1}^{i} \mathbb{x}\_{j, i-j+1} & \text{for} \quad 1 \le i < L\\ \frac{1}{L} \sum\_{j=1}^{L} \mathbb{x}\_{j, i-j+1} & \text{for} \quad L \le i \le K\\ \frac{1}{N - i + 1} \sum\_{j=i-K+1}^{N-K+1} \mathbb{x}\_{j, i-j+1} & \text{for} \quad K \le i \le N. \end{cases} \tag{2}$$

By selecting certain subset indices *I* = *i*1, *i*2, . . ., *il*, one can reconstruct the time series. By observing the distance between the *l*-dimensional matrix and the test time series matrix, we can detect the anomaly by identifying a significant increase in the distance. The SSA-based Change-Point detection utilized in the paper can be described in following stages [41]:

**Stage 1: Construct Base Matrix** First, construct the base matrix (or target matrix) according to the four steps of the SSA algorithm. Given the target time series X = [*xn*+1, ..., *xn*+*N*], embed it into the trajectory matrix *X* = [*X*-1, *X*-2, ..., *X*-*<sup>K</sup>*], where *K* = *N* − *L* + 1. Then, the columns of the trajectory matrix are the vectors:

$$\mathcal{X}\_i = (\mathbf{x}\_{n+i\prime} \dots \mathbf{x}\_{n+L+i-1})^\prime, i = 1, \dots, \mathbf{K}. \tag{3}$$

Then, conduct the SVD and get L eigenvectors which can be grouped into certain subset *I* = *i*1, *i*2, . . ., *il*, *l* < *L*.

**Stage 2: Construct TestMatrix** Similarly, we select integers *p*, *q* and *Q* where *Q* = *q* − *p* > 0. Then, we construct the test matrix of size *L* × *Q*:

$$X\_{\text{test}} = [X\_{p+1}^{\text{"}}, X\_{p+2}^{\text{"}}, \dots, X\_{p+Q}^{\text{"}}]\_{\text{'}} \tag{4}$$

and the columns of the matrix are the vectors:

$$X\_j = (\mathbf{x}\_{n+j}, \dots, \mathbf{x}\_{n+L+j-1})', j = p+1, \dots, p+Q,\tag{5}$$

**Stage 3: Compute the Detection Statistics** In this stage, we first compute *Dn*,*I*,*p*,*q*, the sum of the squared Euclidean distances between the *l*-dimensional subspace from the base matrix and the vectors *X<sup>j</sup>*(*j* = *p* + 1, . . ., *p* + *Q*)from the test matrix.

$$D\_{n,l,p,q} = \sum\_{j=p+1}^{q} ((\vec{X}\_{\vec{j}})^T \vec{X}\_{\vec{j}} - (\vec{X}\_{\vec{j}})^T \mathcal{U} \mathcal{U}^T \vec{X}\_{\vec{j}}).\tag{6}$$

Then, we give the normalized sum of squared distances

$$S\_n = \frac{1}{\mu\_{n,I}} \mathcal{D}\_{n,I,p,q\prime} \tag{7}$$

where *D*˜ *<sup>n</sup>*,*I*,*p*,*<sup>q</sup>* = <sup>1</sup> *LQ Dn*,*I*,*p*,*<sup>q</sup>* and *<sup>μ</sup>n*,*<sup>I</sup>* <sup>=</sup> *<sup>D</sup>*˜ *<sup>m</sup>*,*I*,0,*<sup>K</sup>* is the estimator and we make the hypothesis that no change of time series structure occurs at the time intervals where *m* is the largest value of *m* ≤ *n*.

We also compute the Cumulative Sum (CUSUM) *Wn* of the normalized sum of squared distances as the final score for the anomaly detection.

$$\mathcal{W}\_1 = \mathcal{S}\_1, \mathcal{W}\_{n+1} = \max\{0, \mathcal{W}\_n + \mathcal{S}\_{n+1} - \mathcal{S}\_n - \kappa/\sqrt{LQ}\}, n \ge 1,\tag{8}$$

where *κ* is a constant, and in this paper, we set *κ* = 1/(3 <sup>√</sup>*LQ*) [43].

**Stage 4: Set threshold and make decisions** To detect the change of the time series, we could check the values of *Dn*,*I*,*p*,*q*, *Sn* and *Wn*. Basicallys the large value of the three detection statistics indicates the change or the anomaly. In this paper, we choose the *Wn*-based detection algorithm as it gives greater sensitivity compared with the former two detection statistics [41]. The algorithm announces a structural change if we observe *Wn* > *h* for some *n* where *h* is the threshold given by

$$h = \frac{2t\_a}{LQ} \sqrt{\frac{1}{3}Q(3LQ - Q^2 + 1)},\tag{9}$$

and *t<sup>α</sup>* is the 1 − *α*-quantile of the standard normal distribution [41].

#### *4.4. Proof-of-Behavior Consensus Algorithm for Fair Mining Enforcement*

The abovementioned SSA-based detection can identify a single misbehaved miner based on its own footprint; however, it cannot handle byzantine scenarios that multiple compromised miners by an adversary collude to violate fair mining policies. By observing a miner's running operations, the calculated cumulative sum (CUSUM)-type *W* can indicate a miner's behavior. Inspired by deepfake detection in video surveillance systems [44,45], our MinT relies on a novel *Proof-of-Behavior* consensus algorithm that leverages CUSUMtype *W* calculated in SSA algorithm to detect multiple dishonest miners in distributed byzantine tolerant scenarios.

We consider a mining network N including *ni* miners, where *i* ∈ {1, *k*} and *k* = |N |. All dishonest miners are denoted by *mi* ∈ M and their fraction is *f* = |M|/|N |. We use observed CUSUM-type *Wi* of miner *ni* to demote a behavior vector *Bi* = {*b*1, *b*2, ..., *bd*}, where *bk* = *wk* ∈ *Wi* and *d* is the SSA detection time window. Finally, each twin can maintain a global view of collected behavior vectors, which is a matrix *G* = {*B*1, *B*2, ..., *Bk*}. The PoB firstly generates a behavior score *s*(*i*) for each miner *ni*, which is a sum of relative Euclidean distances between other miners' behavior vector. Then, a *Bi* ∈ *G* with minimal behavior score is selected as a benchmark *B*∗.

The PoB consensus algorithm aims to chooses a behavior vector *B*, which deviates at least from the distribution of *G*. However, an adversary can compromise multiple miners that generate large vectors to force "honest" miners to choose a byzantine behavior vector as the ground truth one. Thus, our PoB algorithm adopts a *Krum* aggregation rule to guarantee byzantine tolerance. We assume that honest miners within network N store *G* including *n* ≥ 2 *f* + 3 vectors in which at most *f* vectors are generated by byzantine nodes in M. For *Bj* belongs to the *n* − *f* − 2 closest vectors to *Bi*, where *i* = *j*, we denote *i* → *j*. Therefore, we could define the consensus score:

$$s(i) = \sum\_{i \to j} \left| |B\_i - B\_j| \right|^2. \tag{10}$$

Then, each node can compute behavior scores *s*(1), ...,*s*(*k*) that are associated with miners *n*1, . . ., *nk* separately. By calculating the minimum behavior score

$$s^\* = \min\_{i \in \{1, \ldots, k\}} (s(i))\_\prime \tag{11}$$

all honest miners choose a behavior vector *Bi* that satisfies *s*(*i*) = *s*<sup>∗</sup> as the ground truth *B*∗. Given assumption that an adversary controls no more than *f* miners, all honest miners can reach an agreement on the unique *B*∗.

#### **5. Experimental Study**

In this section, a proof-of-concept prototype implementation and experimental configuration are described. Following that, we evaluate effectiveness of the proposed MinT

solution based on numerical results. Finally, we discuss performance and security properties provided by MinT.

#### *5.1. Experimental Setup*

A proof-of-concept test platform is created, in which 16 Raspberry Pis (RPi) are adopted as the edge devices. Each RPi is empowered with quad-core Cortex-A72 CPU @1.5GHz and an installed RAM with 4GB memory running Raspbian OS based on Debian. The single-board computer (SBC) is capable of carrying containerized PoW module to participate the blockchain network. A desktop functions as a fog server, which has Intel Core i7-7700K CPU and a RAM of 16 GB memory. All of the RPis are connected to a fog server via local area network (LAN).

As the GPU is not available on the RPi, we select a CPU-based PoW algorithm for container construction. For fast deployment, Docker [46] is adopted as the microservice container that is affordable to RPis and transmits the data from the physical miner to a fog server through RESTfull APIs. Each of the miner containers is configured with and restricted to one CPU core, 500 MB memory and 10 percent of system I/O bandwidth. The collected data are stored in forms of vector as described in Section 4.2.

As the PoW algorithm is executed on CPU, samples of the key parameter *C* are collected and the historical data vector *chi* is used to obtain the statistic profile, where *h* = 1, ... , 16 and *i* = 0, 1, .... For SSA based change-point detection, as the standard SSA recommendation in the book [47], we define *N* = 24 according to the size of the data sets, *L* = 12 to the half size of *N*, *p* = 12, *q* = 24 and *d* = 1*s*. We deliberately set *p* ≥ *K* so that the base and test matrices would not coincide. After visual inspection of the components of the decomposition of the whole time series, we choose certain *l* to represent ignoring the noise components. To guarantee the accuracy and reliability, we repeat each experiment scenario for at least five times and over two hours each time to avoid contingency.

#### *5.2. Experimental Results*

All 16 miners, by default, run at 100% of the assigned system resources under the jurisdiction of the fog server. Four different test scenarios are considered in our experimental study. To verify SSA-based detection on a single misbehaved miner, we first conduct test cases that only one dishonest miner uses double-assigned computation power on mining given a different parameter combination. Then, we consider a more stealthy single miner violation, which incrementally increases the computing power from 20% up to 50%. To validate effectiveness of PoB-based detection, we simulate a byzantine network, in which two miners act as byzantine nodes while 14 miners are honest members. Finally, we evaluate the false-positive rates at the network level with different threshold settings.

#### 5.2.1. SSA-Based Detection on Static Single Miner Violation

In this scenario, one dishonest miner uses twice as much CPU power as the assigned amount at *t* = 200 s. Figure 3a presents the network level observation at the fog server. The blue line is the average CPU usage for all 16 miners in this blockchain network, and the red line is the *wn* value calculated using SSA algorithm as the score. The green line is the threshold *h* = 0.607, which is computed with *t<sup>α</sup>* = 1.2815. As shown by Figure 3a, the fluctuation in the average CPU utility incurs a low peak in the distance score. However, applying the SSA algorithm on each miner twin individually avoids the false negative. Figure 3b shows that a significant peak is observed at *t* = 200 s.

We also studied the impacts of different selections of the SSA parameters varying *l* and *q* − *p* combination. Figure 3c shows the consequence of increasing the value of *l* from 4 to 8 but with the same matrix size. The larger *l* leads to a more noise part with the signal; therefore, it would be more difficult to find a change in the signal time series. If the *l* is too small, which would cause underfitting, we might miss some part of the signal. Due to limited space, the figure is not included here.

Meanwhile, the matrix size *q* − *p* also has significant impact on the detection distance score. Figure 3d shows that, by increasing the value of *q* − *p* to 24 while *l* = 4, the distance (red) line is smoother than in Figure 3b.

**Figure 3.** SSA detection on single miner violation with different parameter combinations. (**a**) Network level observation at the fog server; (**b**) Observation on a single miner; (**c**) Impacts of increasing *l* from 4 to 8 with the same matrix size; (**d**) Impacts of increasing the matrix size to 24 while maintain *l* = 4.

#### 5.2.2. SSA Detection on Adaptive Single Miner Violation

The second scenario considers more stealthy behavior of a violator, which increases the computing power slowly, from 20% to 50%, taking multiple steps at time point *t* = 125 s, *t* = 175 s, *t* = 225 s and *t* = 275 s. Figure 4a shows the detection results in which a miner increases 20% CPU usage at each time point. Figures 4b–d show similar results of cases when the CPU usage increases by 30%, 40% and 50% respectively. Obviously, the SSAbased anomaly detection is able to detect the changes in the structure of the time series data and to identify the corresponding violation on mining power. However, the critical issue is how to select a threshold to ensure a high detection accuracy and to minimize the false-positive/negative rates.

#### 5.2.3. PoB-Based Fair Mining Detection Effectiveness

We take an observation of 20 min on the 16 miners running at 100% of the assigned system resource. Two of the miners act as the byzantine (dishonest) workers, which would gain extra 10% at the 9th and 10th min. As shown in Figure 5a, the behavior vector *B* from dishonest workers varies from honest ones when the byzantine workers gain more computing power. During the two minutes where violation occurs, the resulting consensus scores associated with the byzantine nodes are much larger, as shown in Figure 5b.

**Figure 4.** SSA detection on single miner violation with additive CPU usage. (**a**) One single miner increases 20% CPU usage at each time point; (**b**) One single miner increases 30% CPU usage at each time point; (**c**) One single miner increases 40% CPU usage at each time point; (**d**) One single miner increases 50% CPU usage at each time point.

**Figure 5.** Behavior score distribution with sequential time spots. (**a**) The behavior vector from dishonest workers (red) varies from honest ones (green) when the byzantine workers gain more computing power; (**b**) Comparison between consensus scores associated with the byzantine nodes (red) and the honest nodes (green).

#### 5.2.4. Fair Mining Violation Detection Performance Analysis

The fourth scenario is designed to mainly test the false positive rate from the network level observation at the fog server with different threshold settings. Figure 6 shows the false alarm rates when two of the sixteen miners gain extra system resources from 10% to 80%. The false alarm rate is calculated by comparing the averaged the *W* value with the threshold *h*. When we decrease *h* from 0.6 to 0.03, the false alarm rate increases rapidly at the beginning and then slowly approaches one. With the increasing percentage of the computing power the dishonest miner gains, the false alarm rate grows.

**Figure 6.** False alarm rate with different threshold h.

#### *5.3. Discussions*

The experimental results presented in this section are merely a preliminary study on top of a proof-of-concept platform. Our MinT relies on a permissioned network to provide basic security primitives, such as identity registration, authentication and access control, etc. Given the assumption that the adversary cannot control microservice control the module to send false parameters, we verify that SSA-based detection can identify a single dishonest miner that uses either static or adaptive mining violation strategies. Regarding byzantine scenarios that multiple dishonest miners collude to disturb fair mining mechanism, the PoB consensus algorithm adopts Krum rule in behavior score calculation, which only chooses *n* − *f* − 2 closet behavior vectors and precludes those *f* − 1 malicious vectors that are far away from the center of distribution. Given the assumption that an adversary cannot control more than *f* nodes of a mining network N that satisfies *n* ≥ 2 *f* + 3, all honest participants can still make agreements and output the unique benchmark behavior vector *B*∗.

Our MinT architecture envisions large-scale IoT networks based on a hierarchy of edge-fog-cloud paradigm. However, there are open questions that need to be addressed before bringing the proposed framework into real-world applications. We leave them for our future work.


work is promising to handle the trilemma in blockchain solutions that decentralization, security and scalability cannot perfectly co-exist [4].

#### **6. Conclusions and Future Work**

In this paper, we proposed MinT, an edge-fog-cloud architecture to enable a fair PoW consensus mechanism by leveraging miner twins. Experimentally, the paper validated the feasibility of the concept of using DT to monitor the miners' behaviors and to deter selfish nodes who violate the fair-mining rule. The reported preliminary results verify the effectiveness of using quick change point detection and the PoB consensus algorithm to catch fair mining violators; however, more intelligent solutions are needed to support dynamicity and optimization in fair mining network. Moreover, the above mentioned open questions need to be addressed in IoT-based mining networks. Our future work includes the following.


**Author Contributions:** Conceptualization, Q.Q., R.X. and Y.C.; methodology, Q.Q. and R.X.; software, Q.Q. and R.X.; validation, Q.Q., R.X. and Y.C.; formal analysis, Q.Q. and R.X.; investigation, Y.C.; resources, Y.C., E.B. and A.A.; data creation, Q.Q.; writing—original draft preparation, Q.Q. and R.X.; writing—review and editing, Y.C., E.B. and A.A.; visualization, Q.Q. and R.X.; supervision, Y.C. and E.B.; project administration, Y.C. and A.A.; funding acquisition, Y.C. All authors have read and agreed to the published version of the manuscript.

**Funding:** This work is partially supported by the U.S. National Science Foundation (NSF) via grants CNS-2141468.

**Data Availability Statement:** Not Applicable, the study does not report any data.

**Acknowledgments:** The views and conclusions contained herein are those of the authors and should not be interpreted as necessarily representing the official policies or endorsements, either expressed or implied, of the U.S. Air Force.

**Conflicts of Interest:** The authors declare no conflicts of interest.

#### **Abbreviations**

The following abbreviations are used in this manuscript:



#### **References**


## *Article* **Utilizing Blockchain for IoT Privacy through Enhanced ECIES with Secure Hash Function**

**Yurika Pant Khanal 1, Abeer Alsadoon 1, Khurram Shahzad 1,\*, Ahmad B. Al-Khalil 2, Penatiyana W. C. Prasad 1, Sabih Ur Rehman <sup>1</sup> and Rafiqul Islam <sup>1</sup>**


**Abstract:** Blockchain technology has been widely advocated for security and privacy in IoT systems. However, a major impediment to its successful implementation is the lack of privacy protection regarding user access policy while accessing personal data in the IoT system. This work aims to preserve the privacy of user access policy by protecting the confidentiality and authenticity of the transmitted message while obtaining the necessary consents for data access. We consider a Modified Elliptic Curve Integrated Encryption Scheme (ECIES) to improve the security strength of the transmitted message. A secure hash function is used in conjunction with a key derivation function to modify the encryption procedure, which enhances the efficiency of the encryption and decryption by generating multiple secure keys through one master key. The proposed solution eliminates user-dependent variables by including transaction generation and verification in the calculation of computation time, resulting in increased system reliability. In comparison to previously established work, the security of the transmitted message is improved through a reduction of more than 12% in the correlation coefficient between the constructed request transaction and encrypted transaction, coupled with a decrease of up to 7% in computation time.

**Keywords:** Internet of Things; blockchain; ECIES; secure hash function; privacy; reliability

#### **1. Introduction**

With the recent advances in technology, several Internet of Things (IoT) devices are being developed and implemented in our day to day life. These IoT devices collect personal data from the user to carry out different processes across several applications. Given the involvement of these devices in our daily life, the collected data are prone to a variety of security and privacy threats [1,2], in particular the monitoring of user's activities and profile creation [3]. Moreover, users do not have control over their data and necessary information regarding how it is being collected and how it is further processed. It thus becomes essential to protect the privacy rights of the users and facilitate them with the ability to control their transmitted data under the IoT landscape.

Data profiles can be utilised for individual identification purposes and therefore, collecting data and creating user data profiles pose a severe threat towards privacy and personal integrity. Even if the IoT data are not connected directly to an individual, it is possible to collect IoT data and create profiles of individuals. These profiles can be used to identify individuals or groups of individuals and pose a direct threat to user privacy. If data from IoT devices are combined with data from other sources such as social media, the identification of groups and/or individuals becomes much easier. One of the most critical parts of data collection via IoT devices is that most of the time, consumers are not aware of what data are being collected and how they are being used. Even in cases

**Citation:** Khanal, Y.P.; Alsadoon, A.; Shahzad, K.; Al-Khalil, A.B.; Prasad, P.W.C.; Rehman, S.U.; Islam, R. Utilizing Blockchain for IoT Privacy through Enhanced ECIES with Secure Hash Function. *Future Internet* **2022**, *14*, 77. https://doi.org/10.3390/ fi14030077

Academic Editors: Rattikorn Hewett and Paolo Bellavista

Received: 10 January 2022 Accepted: 24 February 2022 Published: 28 February 2022

**Publisher's Note:** MDPI stays neutral with regard to jurisdictional claims in published maps and institutional affiliations.

**Copyright:** © 2022 by the authors. Licensee MDPI, Basel, Switzerland. This article is an open access article distributed under the terms and conditions of the Creative Commons Attribution (CC BY) license (https:// creativecommons.org/licenses/by/ 4.0/).

where consumers agree to the collection of data for a specific application, it is difficult for them to perceive the number of ways that data may be used in the future. The work of [4] investigates the possibilities to recognise a user based on when they communicate, what kind of applications they use, the type of devices they are surrounded by and their geographical location.

Traditionally, a user's sensitive data are stored on centralized servers [5], which can be easily tampered by the third party resulting in additional security and privacy threats, since user data was accessible without obtaining consent from the user. To address this issue, Blockchain-based solutions have been proposed in the IoT system, where several approaches have been advocated to protect user privacy [6–10]. Blockchain technology has dramatically enhanced user privacy and data access owing to its decentralized nature, enabling all participating nodes in the Blockchain to provide services equally [11]. In case of a node failure, other nodes keep providing the service, removing single point of failure that is a major problem in the traditional methods. The immutability feature of blockchain technology protects the data from being tampered and safely store the data in the form of blocks [12]. These features of blockchain technology eliminate the limitations of traditional centralized servers used in IoT applications. However, they still suffer from issues such as privacy protection and behavior regulation of access policy. In order to trace the real identity in an unusual transaction and preserve the privacy of the user in the data access policy, it is necessary to protect authenticity and confidentiality of the transmitted message while obtaining the consent needed for data access in the IoT system.

Our focus in this work is on protecting the confidentiality and authenticity of user consents during data transmission in IoT systems. We aim to preserve user privacy by maintaining the integrity of user consents before data transmission takes place in the IoT network. To improve the security strength of the encryption and decryption keys of the request transaction and response, we propose a two-pronged approach. Firstly, we proposed the use of a Secure Hash Function (SHF) [13] to derive private and public keys and secondly, we recommend the use of Key Derivation Function (KDF) to derive multiple keys to prevent the attacker from detecting the actual key value. The improved security strength decreases the correlation coefficient between constructed request transactions and encrypted transactions, enhancing user privacy in IoT systems. The proposed solution also improves the reliability of the system compared to a recent work of Lin et al. [14] by eliminating user-dependent variables and reducing the computation time.

The rest of the paper is organized as follows: Section 2 discusses in detail the recent advances in blockchain security measures, with a focus on its application in the IoT landscape. We detail the proposed scheme in Section 3, providing the major steps and associated details. Section 4 discusses the benefits of the proposed scheme, providing comparison to related works. In Section 5, we present analysis and detailed results of our scheme, demonstrating the efficacy in terms of average correlation coefficient and computation time, whereas the interim results on different datasets are also provided. Finally, the paper is concluded in Section 6, provisioning some future research directions.

#### **2. Related Works**

Blockchains are tamper evident and tamper resistant digital ledgers implemented in a distributed fashion, usually without a central authority. At their basic level, they enable a community of users to record transactions in a shared ledger such that under normal operation of the blockchain network, no transaction can be changed once published [15]. Unlike traditional methods, blockchain enables peer-to-peer transfer of digital assets without any intermediaries. Blockchain is often regarded as a public ledger in which all committed transactions are stored in a chain of blocks, and this chain continuously grows when new blocks are appended to it. The blockchain technology's key characteristics include decentralisation, persistency, anonymity and auditability.

#### *2.1. Ethereum Public Blockchain*

Ethereum represents a blockchain providing an abstract layer that enables all users to create their own rules for ownership, formats of transactions, and state transition functions, which is achieved through the use of smart contracts [16]. The consensus in the Ethereum network is based on modified GHOST protocol. Ethereum is created to tackle the issue of stale blocks in the network since the GHOST protocol includes stale blocks into calculations of the longest chain. The authors in [17] enhanced user privacy in a mobile crowdsensing system with spatial location privacy-preserving and greedy algorithms to improve data quality and preserve location privacy. They constructed a blockchain-based location privacy-preserving mobile crowdsensing system where the decentralization and immutability of Blockchain avoids security issues. However, the algorithm used in this scheme is based on the estimated value, so any inaccurate estimate may lead to significant problems and does not ensure data quality and reliability of the system.

In [18], the focus was on enhancing a smart healthcare system using a blockchain to preserve the privacy of the health data and ensure that diagnoses are not tempered. The proposed solution decreases the computation and communication cost comparing to the traditional system when preserving privacy in smart healthcare. However, the computation time is not fixed as the scheme requires users to update their key each time the transaction is updated. The researchers in [19] designed and implemented a decentralized reputation system to develop trust in the public fog nodes for enabling the IoT devices to rely on them securely. It provides safety against security vulnerabilities associated with IoT data and maintains the integrity of the data. The method uses the opinions of multiple users regarding the performance of public fog nodes to calculate reputation score for the future user to uses this system, which shows the unreliability of the system performance since the change in users' opinions changes the reputation score and increases the computation cost. Several computing task offloading schemes in mobile edge computing for IoT devices have been developed in [20]. The developed system uses a Blockchain-enabled edge computing framework and non-dominated sorting genetic algorithm to maintain data integrity while performing a task offloading process. Moreover, it adopts simple additive weighting and multi-criteria decision making techniques to select the most suitable offloading schemes. The task offloading system consumes 5% less energy than compared methods and decreases offloading time and energy consumption with data integrity and privacy protection. However, this work does not consider the security of VM instances while moving from one edge computing device to another device for obtaining load balance.

#### *2.2. Consortium Blockchain*

Consortium blockchain is a type of blockchain with authorized nodes to maintain distributed shared databases. Constructed by several organizations, the consortium blockchain is partially decentralized as only a small portion of nodes would be selected to determine the consensus. Among other advantages, recent works [21] have shown that it offers high potential for the establishment of decentralized electricity trading system with moderate cost. The authors of [22] propose a blockchain-based secure and privacy-preserving personal health information sharing scheme for diagnosis improvements in e-Health systems, where private and consortium blockchain are constructed by devising their data structures, and consensus mechanisms. In order to achieve data security, access control, privacy preservation and secure search in this work, all the data including the health information, keywords and the patients' identities are public key encrypted with keyword search. In [23], the authors construct a consortium blockchain framework for detecting malicious codes in malware and extracting the corresponding evidences in mobile devices. The work performs feature modelling by utilizing statistical analysis method, where the framework is composed of a detecting consortium chain shared by test members and a public chain shared by users. The authors also design a multi-feature detection method of

Android-based system for detecting and classifying malware, and establish a fact-base of distributed Android malicious codes by blockchain technology.

#### *2.3. Hyperledger Fabric Blockchain*

Hyperledger Fabric is an implementation of a distributed ledger platform for running smart contracts, leveraging familiar and proven technologies, with a modular architecture allowing pluggable implementations of various functions [24]. Designed as an extensible general-purpose permissioned blockchain, Hyperledger Fabric is the first blockchain system that supports the implementation of distributed applications written in standard programming languages [25]. This essentially allows them to be executed consistently across many nodes, giving impression of execution on a single globally-distributed blockchain computer, making Fabric the first distributed operating system for permissioned blockchains. The authors of [26] showed that the security can be enhanced by using proof of block and trade consensus algorithms to validate trade and blocks before allocating them to the ledger. Their solution uses a lightweight consensus algorithm, resulting in reduced computation time. However, it is resource intensive as it requires each trade to be validated before and at the time of block formation.

In [27], the authors proposed to improve privacy in industrial IoT with a Blockchainbased secure data sharing model for distributed multiple parties. They used federated learning algorithms to transform raw data generated in industrial IoT into the corresponding data model and share it. This model helps prevent data leakage, and data owners can assess before giving access to share their data in Industrial IoT. It provides high efficiency and enhanced security over traditional solutions. However, stable accuracy is difficult to achieve with the increase in the number of data providers. Also, an increase in the number of data providers requires a system to scale data for performing the computation. The consensus protocol is enhanced in [28] by checking the data loss before the data transmission to the blockchain network. This system uses a gossip-based diffusion function that guarantees the data collected from the sensor device are transmitted to the honest node of the blockchain network. However, this system does not consider the traffic that may increase in the network when the nodes are busy in replicating the processing outcome. The improvement of privacy with novel blockchain-based distributed key management scheme was discussed in [29], which eliminates the potential threat caused by a trusted third party. It uses multi-blockchain network that improves verification and saves storage space for IoT devices. The results showed that the scalability of the system is suitable to resource constrained IoT systems. However, a preshared key strategy in asymmetric cryptography is used, resulting in increased computation and communication overhead.

#### *2.4. Blockchain Mechanisms for IoT Security*

Blockchain-based frameworks to preserve user privacy in IoT have been proposed in a majority of works. The authors of [30] proposed a blockchain-based data acquisition scheme for a secure collection of data from IoT devices using Unmanned Aerial Vehicles (UAVs). This solution was researched by collecting data from IoT devices using UAV and storing safely in blockchain through mobile edge computing. However, in this approach, the required verification increases the latency. The researchers in [31] enhanced privacy in IoT with the Hyperledger Fabric Blockchain framework and Attribute Based Access Control (ABAC) to ensure efficient access control even under large number of requests in the IoT environment. The performance of this approach is analysed using two terminals which may increase the computational cost. The authors of [5] enhanced the publish/subscribe model with a blockchain-based secure publish/subscribe system to protect the privacy of publishers and subscribers. This model uses the Ethereum platform to ensure identity protection of the publisher and subscriber, using public key encryption with an equality test to guarantee the confidentiality of IoT data transmitted in the blockchain network. Though the authors present a promising way to preserve privacy in IoT system, the use of

Diffie–Hellman protocol for encryption procedure does not resist security attack, causing the user to compromise the security of their personal data.

Based on consortium blockchain, the security and privacy in IoT were enhanced in [32] with a novel attribute-based access control scheme. This scheme avoids the need to maintain an access control list in the IoT system as compared to traditional access control technologies. The access policies are made up of attributes and stored in the form of transaction in the blockchain. The performance analysis of their system shows storage overhead increases linearly with an increase in the number of attributes, whereas the computation overhead is also linear in the number of attributes. The security analysis shows that their scheme provides resistance to various security attacks in the IoT system. However, the key pair developed for authentication of the transaction does not boost the security strength of the encrypted transactions. In [14], the authors enhanced user privacy preservation in the IoT system with a novel secure mutual authentication system to provide traceability and privacy protection of access policy and user consent. The use of ECIES protects the confidentiality and privacy of request transaction message and response data that is transmitted to obtain necessary consents before data transmission in IoT. It gives a correlation coefficient of 0.34499 between constructed request transactions and encrypted transaction with a computation time of 102.733 ms. The ECIES is implemented to generate the public/private keys for encrypting and decrypting the request transaction data and response data. However, keys generated from the publicly exposed point on the elliptic curve result in violating user privacy.

A major concern regarding the adoption of blockchain technology in IoT networks is the enormous energy consumption associated with blockchains. This perception inevitably raises concerns about the further adoption of this technology, a fact that inhibits rapid uptake of what is widely considered to be a ground-breaking and disruptive innovation [33]. This fact, along with the significant increase in energy consumption caused by IoT networks has created a new challenge and diverted the focus towards creating an eco-friendlier IoT ecosystem, which provides energy efficient services and enables the production and use of renewable energy [34]. The combination of blockchains and a green IoT is focused on reducing energy consumption and adopting renewable resources rather than on energy generated by fossil fuels. Furthermore, recent studies [33,35] have shown that blanket statements about the energy consumption related to blockchains should be reviewed with care. Although Bitcoin and other proof-of-work blockchains do indeed consume a lot of power, alternative blockchain solutions with significantly lower power consumption are already available today, and new promising concepts are being tested that could further reduce the power consumption of large blockchain networks.

#### **3. Modified ECIES with Secure Hash Function**

The proposed scheme is intended to protect the integrity of transmitted messages while obtaining necessary consents for data transmission in IoT. Moreover, it provides resistance against different attacks and ensures reliable auditing of the user data access policy. To provide confidentiality and authentication of the transmitted data, both the request transaction and response data are authenticated once they are encrypted. We have chosen the proposed method in Lin et al. [14] as the basis for our designed solution. The mutual authentication system shows the access request transaction and response data while obtaining necessary consents. It protects against any data leakage and data loss, ensures reliable behavior auditing and protects the user access policy, preventing any malicious attack and possibility of consents versioning. The request transaction data are encrypted using ECIES and authenticated using message authentication code. The access request transaction and response data are firmly secured and authenticated, providing enhanced security while managing user data access policy and consents [18].

The use of an SHF to generate private and public keys prevents an attacker from detecting the actual values of the keys from which it is derived, even in the case where the hash function is known. This feature enhances the privacy preservation in IoT, providing

resistance to detect the actual value of the key is used to encrypt the message. A detailed flow diagram of the proposed scheme is shown in Figure 1. In the following, we detail the major stages involved in our proposed scheme.

**Figure 1.** Flow Diagram of the Proposed Scheme—Modified ECIES with Secure Hash Function.

**System Setup**—The setup and enroll algorithm is invoked in this step to obtain keys for signing and verifying the transaction. After taking in the security parameters, *λn*, to obtain the public parameters, *σn*, we first generate a hash to ensure the security of the derived key, since the generated hash function is used to compute the private and public keys, denoted by *δ<sup>R</sup>* and *δP*, respectively. The unique hash generation, corresponding to message *m*, is denoted as:

$$h(m) = \psi(m) \quad | \quad \psi: \{0, 1\}^\* \to \{0, 1\}^{256},$$

where *ψ* is the unique hash generation function [30,36], and we have used SHA-256. In some works, for example, [14], the private and public key is calculated from publicly exposed points on the elliptic curve that can be easily detected by the attacker, and user privacy can be compromised. The security strength of the key ensures the confidentiality and authenticity of the transmitted message for obtaining the user consents before processing the user data.

The security strength of the key ensures the confidentiality and authenticity of the transmitted message for obtaining the user consents before processing user data in IoT. Thus, if SHF is used to determine the value for the key rather than choosing publicly exposed points on the elliptic curve, the transmitted message will be highly protected. The secure hash value is used to generate the private key rather than randomly choosing a publicly exposed point on the elliptic curve as a private key and computing public key from the chosen private key. The private key *δ<sup>R</sup>* is generated based on the hash function using the key generator function Γ(·), given as:

$$
\delta\_R = \Gamma(h) \quad | \quad \Gamma : \{0, 1\}^\* \to \{0, 1\}^\kappa,
$$

where *κ* is the designated key size [30,36]. After the generation of private key *δ<sup>R</sup>* from the hash *h*(*m*), corresponding to message *m*, the public key *δ<sup>P</sup>* is calculated based on:

$$
\delta\_P = \delta\_R \* (E\_{x\nu} E\_y)\_{\nu}
$$

where (*Ex*, *Ey*) corresponds to the *x* and *y* coordinates of the point *P* on the elliptic curve *E* of finite field and *P* has the order of large prime number *q* [30]. Hence, the use of the hash function protects the value of the key being detected even if the hash function is known. As a result, private and public keys are secured and provide resistance to several security attacks enhancing user privacy protection.

**Request Control**—Once access request is published, new public and private keys are produced to avoid replay attack and profiling [14], where the uniquely generated hash is used to compute the private key instead of a randomly chosen key. The transaction to access the data is constructed and signed using the GSign algorithm. Request transaction data are then encrypted and verified using different keys. Since the randomly generated points on the elliptic curve can be detected by any attacker as multiple keys to encrypt the transmitted message, the proposed solution uses a KDF algorithm [37] to derive multiple keys from one secured master key. KDF follows an iterative process to derive multiple keys and ensure that an attacker is not able to identify origin of the master key [32]. After keys are generated, request transaction data are encrypted using the Enc. algorithm of ECIES and is authenticated using the MAC algorithm, where the encryption process is given by:

$$\mathbb{C}\_P = Encrypt(T\_{r\prime}\delta\_P)\_{\prime\prime}$$

and *CP* represents the encrypted access request transaction data that is then uploaded to the blockchain network.

**State Delivery**—In this phase, consensus nodes in the blockchain network monitor the access request, checking the transaction verification using a signature verification algorithm. If the transaction is verified, it is decrypted using the Dec algorithm of ECIES and private key [14,30], which provides target device information and control orders, given by:

$$(D\_{i\prime}C) = Decay(C\_{P\prime}\delta\_R)\_{\prime\prime}$$

and *Di* and *C* represent the target device and control information, respectively. The consensus node of the blockchain network formats the data request to ensure the data access request is received from a valid requestor. The information access request to the user and response from the user is encrypted and authenticated. The authentication tag is recomputed to ensure the response is received from a valid user. If the authentication tag matches, only then the response from the user is decrypted to obtain response information about the request.

**Chain Transaction**—The transactions are retrieved in the smart contract of the blockchain network, where signatures are verified to check the validity of the transaction. If the transaction is valid, they are collected, and the block is formed. The consensus nodes use the Practical Byzantine Fault Tolerance consensus mechanism to chain the blocks [38]. The user access policy is then updated, which helps in managing consents set by the user.

**Dispute Handling**—The unusual transactions are traced by detecting abnormal and unusual behavior, where GTrace algorithm is executed to reveal the real identity in the unusual transactions. It helps to prevent impersonation attacks by identifying unusual behavior and showing the real identity of the attacker.

The flow of the modified ECIES is shown in Figure 2, whereas the steps of the proposed scheme are shown in Algorithm 1.

**Figure 2.** Flowchart of the Proposed Elliptic Curve Integrated Encryption Scheme with SHF.

#### **Algorithm 1** Proposed ECIES with Secure Hash Utilization.

**Input:** Security parameter *λ<sup>n</sup>* and Transactional Request Data *Tr* **Output:** Response Data

```
1: Generate σn ← λn
2: Compute h(m) ← m
3: Compute δR ← h(m)
4: Compute δP ← δR ∗ (Ex, Ey)
5: Construct T ← δP
6: Encryption CP ← Encrypt(Tr, δP)
7: Authentication Check
  if Tags Match
       (Di, C) ← Decrypt(CP, δR)
  else Reject CP
  end
```
*Computation Time for Proposed Scheme*

In this section, we calculate the computation time of the proposed scheme, which is given as:

$$T = T\_b + T\_{c\_r}$$

where *T* is the final computation time, *Tb* is a computation time for transaction generation and verification, and *Tc* is the initial computation time. Here, *Tb* is given as:

$$T\_b = \sum\_{i=1}^{T\_r} T\_r^i(t) + \sum\_{i=1}^{\frac{N\_s}{2}+1} N\_s^i(t),$$

where *T<sup>i</sup> <sup>r</sup>*(*t*) is a time for generation of one trade, and *N<sup>i</sup> <sup>s</sup>*(*t*) is a time for verification by session node. Moreover, *Tc* is given by:

$$T\_c = T\_1 + T\_h + T\_{2e}$$

where *Th* is the time for generation of hash function, and *T*<sup>1</sup> and *T*<sup>2</sup> correspond to the time of public/private key calculation and public parameter generation.

#### **4. Benefits of Modified ECIES with SHF**

The proposed solution helps improve the confidentiality and authenticity of the transferred message to obtain consents protected by using an SHF to generate private and public keys. This improves the correlation coefficient between transmitted messages and encrypted transactions. Along with this, it also ensures that the attacker is not able to detect the value of the key even in case hash function is known to the attacker because points on the elliptic curve are the order of a large prime number. In some of previous woks, the computation time is affected by the number of users, thus with the increase in the number of users, the computation time also increases, indicating the unreliability of the system. In the proposed scheme, the computation time is calculated by eliminating the user dependent variable, showing a higher system reliability.

SHF is utilized to generate private and public keys for improving the security strength of the transmitted message. The private key is generated from the SHF based on SHA-256, while the public key is calculated from the private key and points on the elliptic curve of the finite field that is the order of a large prime number. Hence, if the attacker tries to compute the point on the curve, they will not be able to detect the value of the key. In order to improve the efficiency of the encryption and decryption, the KDF is used to generate secured multiple keys from one master key. Some previous works [14] randomly select the publicly exposed point on the curve as a value of the key resulting in several security vulnerabilities that impact user privacy. Using publicly exposed points on the curve that are vulnerable to several attacks as a private and public key, will exploit the user privacy in IoT. Hence, the use of SHF will guarantee that the integrity of the key is protected, and the attacker is not able to detect the actual value of the key. In the proposed scheme, we have kept a regard for the authenticity and integrity protection of the transmitted message while consent management for enhancing user privacy in IoT by using ECIES with an SHF generation.

#### **5. Results and Discussion**

This section presents the analysis and results of the proposed scheme. Considering the relevance of Lin et al. [14] to our work, we provide a detailed comparison of our work with the results presented in Lin et al. [14]. MATLAB R2019a was used to implement and evaluate the prototype of the proposed model on a personal computer (PC). For the implementation, 'secp256r1' is used as the elliptic curve domain parameter [39] to develop the public parameter of the elliptic curve, whereas SHA-256 is used to secure the hash function generation. Four groups of 50, 150, 250, 500 device information were used as a dataset, where these datasets were taken from online resources [40]. Ten samples of device information from each group are taken to construct the request transactions. We considered attributes such as device\_ID, device\_Type, device\_Model, and device\_SN (serial number) from the device information for creating the tansaction request. The completed request transaction is encrypted and decrypted for both Lin et al. [14] and the proposed scheme. The strength of the transmitted message is measured in terms of the correlation coefficient between the constructed request transaction and encrypted request transaction. The performance evaluation of the proposed scheme is based on the comparison of correlation coefficient and computation time with that of Lin et al. [14].

We note that the correlation coefficient measures the closeness between the mapped points on the elliptic curve for the constructed request transaction and encrypted request transaction. The lower the value of the correlation coefficient, the more secure the encrypted transaction. We compared samples taken from our result with the device ID attribute of the 50-device group set from the dataset. This result consisted of the encrypted transaction for request transactions in the request control stage for both Lin et al. [14] and the proposed scheme, where the comparison is based on the correlation coefficient between constructed request transactions and encrypted request transactions.

Table 1 includes the device ID attribute of three samples; the constructed request transaction for each device ID and encrypted request transaction in Lin et al. [14] and our proposed scheme. The measured correlation coefficient here improves from 0.3451 to 0.3052 in the first sample of device ID attributes, which clearly demonstrates the improved security strength of the encrypted transaction due to the lower correlation coefficient. Apart from the device ID samples, we tested other attributes of the device information such as device\_Type, device\_Model, and device\_SN attributes. Ten samples were taken from each of the datasets of 50-, 150-, 250-, and 500-device group set. The results are obtained during the request control stages before uploading the request transaction into the smart contract of the blockchain network, and are shown in Tables 2–5, respectively. It is evident from the provided tables that the proposed solution improves the correlation coefficient between the constructed request transaction and encrypted transaction, providing increased security strength of the encrypted transaction.

We also calculate the average values of the correlation coefficient and computation time for the proposed scheme and for Lin et al. [14], as shown in Table 6. The result shows a noticeable improvement in both the correlation coefficient and the computation time compared to Lin et al. [14]. Figure 3 shows the average correlation coefficient results for the proposed scheme and for Lin et al. [14], which demonstrates the security strength of the transmitted message. The results for Lin et al. [14] are shown in blue, while the orange color indicates the result for the proposed solution. Every paired blue-orange bar represents the correlation coefficient of the 50-, 150-, 250-, and 500- device group sets with the attributes device\_ID, device\_Type, device\_Model, and device\_SN, respectively. The average correlation coefficient for the proposed scheme for device\_ID samples of the 50-device group dataset is reduced to 0.30122, whereas it is 0.34499 for Lin et al. [14]. Similarly, the average correlation coefficient for device\_Model samples of 250-device group dataset is also reduced to 0.30359, whereas it is 0.34853 for Lin et al. [14]. Finally, the average correlation coefficient for device\_SN samples of 500-device group dataset for the proposed solution is reduced to 0.30089 comparing to the record of 0.34433 for Lin et al. [14]. We attribute the degree of improvement in the correlation coefficient to the modified private and public keys for encryption in the proposed scheme. The proposed scheme improves the correlation coefficient from 0.04344 to 0.04377 between constructed request transactions and encrypted request transaction, which shows increased security strength of the transmitted message.


*Future Internet* **2022** , *14*, 77

> **Table 1.**

Constructed

 Request Transaction

 and Encrypted Request Transaction

 in Lin et al. [14] and the Proposed Scheme.


*Future Internet* **2022** , *14*, 77

4

5

6

7

8

9

10

 CR2030

01||pk10||CR2030||o

 BM5060

01||pk9||BM5060||c

 AVV56E

01||pk8||AVV56E||r

 PB485D

01||pk7||PB485D||o

 CBT26Z

01||pk6||CBT26Z||c

 HDR6E

01||pk5||HDR6E||o

 XY290P

01||pk4||XY290P||r

 ZxjdriobstJbci

rvpmRtzderighj

abfdelUbjiotHny

GbjiochtgjFcodef

oxchksDLnfkwcy

AchjeoPvmftugy

Kgankobhmenx

 0.3425

 0.3274

 0.3368

 0.3451

 0.3596

 0.3417

 0.3624

 105.4

 104.55

 110.75

 100.3

 104.78

 99.34

 102.45

+8cY{&269f##k!

3!(gOx<@2dn+\*>

rDk##99!hsi\_4%!

 28g(7!kvy>?lb

 "fs9!45@kcql++

 #46e%Jcmp8!(\*

 0x^{gno\*\*57(%

 0.2971

 0.2887

 0.2932

 0.2995

 0.3152

 0.2951

 0.3164

 98.67

 96.77

 101.48

 97.26

 97.73

 95.87

 98.03


**Table 6.** Average Correlation Coefficient and Average Computation Time Results of Lin et al. [14] and Proposed Scheme (from tested samples).


#### *Future Internet* **2022** , *14*, 77

**Figure 3.** Average Correlation Coefficient results for Proposed Scheme and Lin et al. [14].

Figure 4 shows the average computation time results for both the proposed scheme and for Lin et al. [14] by calculating the execution time for each sample. The blue color indicates the results for Lin et al. [14], and the dark orange color indicates the result for the proposed solution. The paired blue-orange bars represent the average computation time for the 50-, 150-, 250-, and 500- device groupsets with the attributes device\_ID, device\_Type, device\_Model, and device\_SN, respectively.


**Figure 4.** Average Computation Time results for Proposed Scheme and Lin et al. [14].

A comparison between our proposed scheme and Lin et al. [14] is presented in Table 7. Both solutions are based on ECIES that protect the confidentiality and privacy of request transaction messages and response data before data transmission in IoT. While Lin et al. [14] is mutually authenticated with ECIES, our proposed model modified the ECIES with an SHF. Using an SHF to derive private and public keys reduces the correlation coefficient, which improves the security strength of the request transaction data. Our contribution relies on the fact that SHF improves the strength of encryption/decryption of the transmitted message by adding new features for calculating private and public keys from the safer elliptic curve point, as compared to the case of Lin et al. [14], which does not use hash function generation in the process of calculating the private and public keys. Moreover, in Lin et al. [14], the security strength of the key was compromised, resulting in the violation of user privacy in IoT. However, to enhance the privacy and reliability of the processed user data in IoT, the new features adopted in the proposed scheme greatly enhance user privacy in the IoT system. The use of KDF during the encryption procedure of the request control stage introduces key stretching capability in the proposed scheme, which helps to derive multiple keys from a single master key. This feature decreases the number of iterations while deriving keys for authentication. As a result, the proposed scheme achieves a reduction in encryption and decryption time. The computation time calculated in the proposed scheme eliminates user dependent variables by including time for transaction generation and verification to calculate computation time. This feature ensures the reliability of the proposed scheme with reduced computation time compared to Lin et al. [14] by an average of 7 ms per number of transactions.

**Table 7.** Comparison between Proposed Scheme and Lin et al. [14].


#### **6. Conclusions and Future Work**

Data security and user privacy have been the emerging needs in the IoT system. In this work, we presented a Blockchain-based scheme to preserve user privacy in IoT. The proposed scheme provides a secure platform that allows the access requester to send the request transaction data and receive the response data for the corresponding request. We propose to use ECIES with SHF, which is the new feature adapted from Lin et al. [14], to protect the confidentiality and authenticity of the transmitted request transaction and response data. The use of an SHF to derive private and public keys enhanced user privacy in IoT. This enhancement could improve the security strength of the request transaction data, which helps to derive multiple keys from the single master key; decreasing the number of iterations while deriving keys for authentication and elimination. As a result, it reduces the computation time in the proposed solution by an average of 7ms per number of transactions compared to the work of Lin et al. [14]. In the future, we need to explore other cryptographic approaches to provide a secure platform for users and data requester to exchange their data in the IoT environment. Future research needs to focus on issues other than protecting the confidentiality and authenticity of the request transaction data and response data to enhance user privacy in IoT, such as investigating and utilizing different techniques to integrate within the blockchain network for achieving enhanced privacy in the IoT system.

**Author Contributions:** Conceptualization, Y.P.K.; Methodology, K.S.; Project administration, A.A. and S.U.R.; Resources, S.U.R.; Supervision, A.A., A.B.A.-K., P.W.C.P., S.U.R. and R.I.; Writing original draft, Y.P.K. and K.S.; Writing—review & editing, K.S. All authors have read and agreed to the published version of the manuscript.

**Funding:** This research received no external funding.

**Data Availability Statement:** Not applicable, the study does not report any data.

**Conflicts of Interest:** The authors declare no conflict of interest.

#### **References**


## *Article* **Securing Environmental IoT Data Using Masked Authentication Messaging Protocol in a DAG-Based Blockchain: IOTA Tangle**

**Pranav Gangwani 1, Alexander Perez-Pons 1,\*, Tushar Bhardwaj 2, Himanshu Upadhyay 2, Santosh Joshi <sup>2</sup> and Leonel Lagos <sup>2</sup>**


**Abstract:** The demand for the digital monitoring of environmental ecosystems is high and growing rapidly as a means of protecting the public and managing the environment. However, before data, algorithms, and models can be mobilized at scale, there are considerable concerns associated with privacy and security that can negatively affect the adoption of technology within this domain. In this paper, we propose the advancement of electronic environmental monitoring through the capability provided by the blockchain. The blockchain's use of a distributed ledger as its underlying infrastructure is an attractive approach to counter these privacy and security issues, although its performance and ability to manage sensor data must be assessed. We focus on a new distributed ledger technology for the IoT, called IOTA, that is based on a directed acyclic graph. IOTA overcomes the current limitations of the blockchain and offers a data communication protocol called masked authenticated messaging for secure data sharing among Internet of Things (IoT) devices. We show how the application layer employing the data communication protocol, MAM, can support the secure transmission, storage, and retrieval of encrypted environmental sensor data by using an immutable distributed ledger such as that shown in IOTA. Finally, we evaluate, compare, and analyze the performance of the MAM protocol against a non-protocol approach.

**Keywords:** IoT; security; privacy; environment; IOTA; Tangle; MAM; directed acyclic graph; blockchain; distributed ledger

#### **1. Introduction**

#### *1.1. Mobile and Electronic Environment*

Current technological and economic advancements are exerting a tremendous influence on the environment, to the extent of raising severe concerns about climate change and pollution. Human activities have an undeniable and ever-increasing impact on the climate system, along with recent developments that are unprecedented and currently acknowledged by the Intergovernmental Panel on Climate Change [1]. Environmental monitoring in this context refers to an Internet of Things (IoT) system where sensors are used to collect useful data about the ecosystem, leading to further discoveries and a better and more comprehensive understanding, to execute specific actions in mitigating and addressing the degradation of the environment [2]. Environmental monitoring in indoor environments is another related field that is now gaining popularity. This has proved essential not only for the building's or housing's residents [3] but also in terms of lowering greenhouse gas emissions [4]. Temperature, humidity, rainfall, atmospheric pressure, light intensity, and air quality, which are impacted by pollutants such as carbon dioxide (CO2), carbon monoxide (CO), sulfur oxide (SOx), volatile organic compounds, and many more

**Citation:** Gangwani, P.; Perez-Pons, A.; Bhardwaj, T.; Upadhyay, H.; Joshi, S.; Lagos, L. Securing Environmental IoT Data Using Masked Authentication Messaging Protocol in a DAG-Based Blockchain: IOTA Tangle. *Future Internet* **2021**, *13*, 312. https:// doi.org/10.3390/fi13120312

Academic Editor: Christoph Stach

Received: 22 October 2021 Accepted: 4 December 2021 Published: 6 December 2021

**Publisher's Note:** MDPI stays neutral with regard to jurisdictional claims in published maps and institutional affiliations.

**Copyright:** © 2021 by the authors. Licensee MDPI, Basel, Switzerland. This article is an open access article distributed under the terms and conditions of the Creative Commons Attribution (CC BY) license (https:// creativecommons.org/licenses/by/ 4.0/).

are among the most commonly measured parameters. CO is a gas that is colorless and odorless but can cause serious harm to the human population and to the environment. When a substance is burned, smoke and fumes are released containing CO. SOx is a group of sulfur chemicals that cause serious harm to the environment. Therefore, monitoring of the environment and pollutants is required to achieve a safe and healthy environmental ecosystem [5].

To achieve the goal of a more distributed environmental ecosystem, algorithmic analysis of a large quantity of data [6] will train models that regularly monitor environmental parameters and notify or respond to anomalies in real-time. For the improvement of environmental monitoring, it is crucial to develop efficacious algorithms and models at a continued pace within the environmental community; fostering confidence in these methods requires publicly validated and verifiable processes. Within this system, devices can receive and submit data in a federated manner, with over-the-air updates as the shared algorithms, and models are enhanced with time.

The data used to train models must be tamper-proof and dependable, and the technique must be secure. This might help acquire the confidence of environmentalists and environmental officials, as well as make data collection for investigations easier. Environmentalists will have to look beyond their present methods to achieve this verified future. The rise of distributed ledger technology has the potential to close this gap. Therefore, we need to evaluate and analyze the performance of distributed ledger systems such as IOTA to securely exchange environmental data [7] and establish trust among environmental professionals.

#### *1.2. Distributed Ledger Technologies*

Distributed databases or distributed ledgers, such as blockchain [8], are managed via a consensus process by nodes in a peer-to-peer network. Despite the fact that all peers participate in maintaining database integrity, this consensus approach eliminates the necessity for a central administrator. Individuals may reclaim control over their data due to the lack of a central controller.

Blockchain was introduced in 2008 [9] as a distributed ledger technology that is decentralized and immutable. These attributes ensure that the data stored on the blockchain is secure, authentic, and distributed among all the peers in the network. There is no third party involved while making transactions on this technology and no central authority that can control it. These features open the door to various application domains and research areas such as IoT, healthcare, environment monitoring, AI, deep learning, security, and IoT data integrity, wherein the data needs to be distributed and tamper-resistant [10] to avoid a single point of failure when stored on a centralized database.

However, blockchain technology is facing several technical challenges despite having a great potential for the construction of future Internet systems [11]. The main challenge or concern is the scalability of blockchain. The time taken to mine a block is about 10 min and the block size is limited to 1 MB only. Moreover, the bitcoin blockchain is not able to deal with high-frequency trading since it is limited to 7 transactions per second. Additionally, the propagation of the blocks will be slow [12] if the block size is large, as it will require more storage space. Since few users would wish to maintain such a large blockchain, this will lead to centralization. Hence, it has been a tough challenge to address the tradeoff between block size and latency. Moreover, there is the possibility of selfish mining strategies, whereby miners can access greater rewards than they are entitled to.

In this paper, we have leveraged environmental sensory telemetry data, which consists of various sensory data parameters such as temperature, humidity, CO, liquid petroleum (LPG), smoke, light, and motion. The data was generated by a series of three customized sensor arrays. Sensor arrays, consisting of an MQ135 hazardous gas detection sensor, DHT22 temperature and humidity sensor, Onyehn IR pyroelectric infrared PIR motion sensor detector, and Anmbest light intensity detection photosensitive sensor were connected

to Raspberry Pi sensory devices. Moreover, these devices were placed in distinct physical locations and variable environmental conditions, as shown in Table 1.



Each of these IoT devices is continuously collecting the sensory values from four sensors at a standard interval of 5 s. The data was collected during the span of "from 07/12/2020 00:00:00 UTC–07/19/2020 23:59:59 UTC" with a total number of "405,184 rows". In this framework, the "ISO standard Message Queuing Telemetry Transport (MQTT)" protocol [13] is leveraged to bind the sensory readings, a unique ID, and a timestamp and broadcast in terms of a single message; a sample payload is shown in Figure 1.

**Figure 1.** Sample JSON payload.

Different consensus protocols and network topologies have been investigated; these are distributed to ensure the integrity of a distributed ledger while providing high transactions per second and zero fees for transactions. Algorand [14], IOTA [15], Hashgraph [16], and Ouroboros [17] are a few prominent protocols that promise to accomplish the aforementioned characteristics. This technology is suitable not just for the future of electronic finance but also for every data-driven industry.

In this paper, we propose an environmental monitoring [18] application of IOTA, which will allow environmental professionals, such as environmentalists and environmental officers, to share and store encrypted IoT sensor data in a secure way for monitoring purposes. IOTA is a permissionless distributed ledger protocol with no transaction fees. Its goal is to address the scalability concerns that have plagued previous distributed ledger technologies. Moreover, we have leveraged the "Masked Authenticated Messaging extension module of the IOTA protocol" in the proposed approach for the secure transmission, storage, and retrieval of encrypted environmental sensor data. The proposed approach is compared with another method without any data encryption protocol and the performance is measured in terms of time taken in the creation, attachment, and retrieval of payloads.

In summary, the contribution of this paper is as follows:


The remainder of the paper is structured as follows. Section 2 illustrates the background technologies for the proposed framework. Section 3 contains the related literature review for choosing this technology and the proposed work. Section 4 highlights the detailed framework of the proposed model. Section 5 showcases the experimental setup, results, and discussion. Finally, Section 6 focuses on a conclusion and future directions in terms of optimizing the MAM protocol for securing sensory data.

#### **2. Background**

This section describes the various technologies utilized for the proposed work in this research.

#### *2.1. IOTA*

The IOTA is a distributed ledger technology to manage secure data transmission between different IoT devices. The main difference between the IOTA and other distributed ledger technologies is that it utilizes the directed acrylic graph (DAG) structure called the "Tangle" in place of the conventional blockchain. IOTA is highly scalable [19] since there are no blocks in its DAG structure, which leads to a faster confirmation of transactions, unlike in the case of blockchain. Making a transaction on IOTA consumes less energy [20] as compared to other distributed ledgers and, hence, the adoption of IOTA in low power devices such as the IoT becomes rudimentary.

The scalable architecture of the IOTA Tangle enables faster transaction confirmation, as shown in Figure 2. In Figure 2, each square represents a transaction and the arrows also known as edges connect these transactions to form a Tangle. There are three types of transactions, called tips, ongoing transactions, and approved transactions, as shown in Figure 2. Tips are the unconfirmed transactions that are new and have just been added to the ledger. Ongoing transactions are the transactions that have been added to the ledger and are waiting to be referenced by new transactions [21] to achieve confirmation. Approved transactions are the transactions that have been confirmed or have been referenced by all the tips, either directly or indirectly.

The working model and the security of the IOTA protocols were designed with quantum computers in mind, as well as environments with constraints on bandwidth. The Winternitz one-time signature system, which protects against quantum computer access, is used in the IOTA protocol. This one-time signature approach enables effective broadcast authentication in sensor networks since the communication and computing needs are low. As there is no transaction fee for publishing a transaction to IOTA, it can be seamlessly used to send transactions, store data, and ensure data integrity with time. A data transmission protocol [22] called masked authenticated messaging (MAM) enables a user to publish streams of encrypted data in the form of transactions. Participants can broadcast a message at any time by forming a channel [23]. Subscribers can subscribe to the channel of the publisher to receive the data by using the address of the transactions. However, a small amount of proof-of-work is necessary for the data to circulate through the network and prevent spamming. MAM allows the user to send encrypted data streams that are a chain of messages or sensor data to IOTA with zero cost per transaction through the Tangle.

**Figure 2.** The DAG structure of the Tangle.

Forward secrecy and quantum-resistant cryptography are the two most important features of MAM implementation. Attacks by a quantum machine [24] that is adequately powerful can be resisted due to the secure post-quantum cryptographic algorithms. Many cryptographic algorithms traversing today over the Internet that are presently used to encrypt data [25] are not sufficiently secure. MAM is a useful protocol to transmit confidential data, due to the feature of forward secrecy. Every transaction is linked to the next transaction with a pointer known as next root, which is a Merkle root of the next transaction. As a result, the transaction at the point of entry and the subsequent transactions linked to it can be retrieved efficiently. However, it becomes infeasible for a user to fetch transactions before their point of entry due to forward transaction linking, as shown in Figure 3.

**Figure 3.** Transaction linking in MAM, displaying forward secrecy.

#### *2.2. Modes and Channels of MAM*

A channel is first established, then the publisher is able to encrypt data with the channel key and publish them into the Tangle. Clients can fetch the transaction from the Tangle and decode the message on it only if they know the MAM channel key. Messages are connected in chronological order and are published on the same channel. If the users gain access to a channel, they cannot view past transactions on that channel before their entry; this provides the notion of forward secrecy [26]. There are three modes of privacy provided by MAM, known as public, private, and restricted, that control visibility and access to the channels. The address of the transaction is the channel ID of MAM in each mode and allows the system to return a MAM transaction [27] by performing a straightforward request to the Tangle. In contrast, to decode the payload, the key provided in the transaction of MAM does not have to be the same as the channel ID. When the current payload is decoded, the user receives the message as well as the channel key for the subsequent message. For both private and public modes, this property becomes useful, as we will see below.

The channel key is the channel ID that makes up the transaction address for the public mode. Thus, all the contents of the message chain can be read by any user on the network. Due to the additional degree of protection, unauthorized users cannot read a message chain in private mode. The channel key is hashed [28], which becomes the channel ID as well as the transaction address. As a result, the channel key must be safely broadcasted to all subscribed users by the publisher in order that the message can be located on the Tangle network.

The next step involves the subscribed users obtaining the channel key's hash by querying the Tangle, using that key to decode the data payload. If an adversary intercepts a transaction of MAM sent in private mode, they will not be able to read or decode the content of the message payload by utilizing the channel ID, since it was produced by hashing the channel key.

Figures 4–6 represent the different channel modes of MAM and how transactions are linked. The root shown in the three figures is also known as the channel key; the address of the transaction is also known as the channel ID. In all three modes, as shown in the figures, each transaction contains a root and next root. The next root of the current transaction becomes the root for the next transaction, as shown. For the public mode, as shown in Figure 4, the transaction address or the channel ID is the same as that of the next root. For the private mode, as shown in Figure 5, the transaction address is the hash of the next root. However, in the restricted mode, as shown in Figure 6, there is an additional key, known as an authorization key, that is used for performing access control on the data. The transaction address for this mode is the hash of the next root, concatenated with the authorization key.

**Figure 4.** The flow of data in public mode.

**Figure 5.** The flow of data in private mode.

Hashing of the authorization key is performed, and the hash is concatenated with the channel key to produce the transaction address of the restricted mode in MAM. The authorization key and the channel key are both necessary for decoding the data payload. The publisher specifies the authorization key and can change it at any time in the channel's stream. This enables the publisher to revoke access [29] in their channel from future messages at any point in time. If access is not granted to the subscriber for the current authorization key, they will be unable to decode and locate subsequent transactions in the chain of messages. As a result, subscribers' access can be revoked at any time using this approach. Figure 7 depicts a simplified representation of the many components that go into building an MAM channel.

**Figure 7.** Generation of channel key, using one-way hash functions.

#### **3. Related Work**

This section provides a detailed review of the literature in which blockchain technology and IOTA have been adopted in the domain of environmental monitoring and other IoT applications.

Bhandary et al. [30] present the use of a DAG-based blockchain structure called IOTA for the secure sharing of sensor data by integrating two technologies. The paper describes the work and the features of IOTA that can enable seamlessly integrating IoT devices with IOTA to safely transmit IoT data into the Tangle. An architecture was presented in the paper that included the use of Raspberry Pi devices to aggregate and send sensor data to the IOTA network. However, the architecture proposed in the paper was highly generic and lacked a working methodology. Moreover, there was no experimental evaluation of the architecture, especially in terms of performance.

Yu et al. [31] analyzed the stereotypical privacy and security issues in IoT and developed a framework that utilized Ethereum blockchain with an IoT system. A four-layered architecture was proposed where blockchain was used at the database layer to adapt to the IoT system. A good theoretical description of how the proposed framework tackles IoT security and privacy issues were provided. However, a proper working model to practically address these IoT security and privacy issues was missing. Furthermore, there was no performance or latency evaluation for the proposed framework.

Lamtzidis et al. [32] proposed a sensor node system that was distributed and utilized the IOTA distributed ledger to exchange data with IoT devices. In this paper, a distributed wireless sensor node system was proposed that ensured integrity of the data across the entire pipeline. The proposed system consisted of three entities: super nodes (SNs) that aggregated the data, full nodes (FNs), which are the IOTA nodes that perform the proof-ofwork (PoW), and a back-end server. However, their proposed method did not show how

the three entities are connected and how the data is flowing. Additionally, there was no implemented architecture and an experimental evaluation of their proposed system.

Yan et al. [33] proposed an environmental monitoring system that uses blockchain to provide integrity to the environmental data and prevent falsification. Additionally, a threedimensional architecture using intelligent trusted devices was presented for environmental monitoring, to ensure the integrity and originality of the data collected by the IoT devices. The raw data from the sensors were transmitted to a whole node that could send data to the blockchain and could synchronize all the data within the blockchain nodes. However, an extensive performance evaluation of the proposed model was missing, which would provide some details on the latency of blockchain operations. Moreover, the traditional blockchain setup cannot meet the scalability demands of the IoT system; hence, a scalable blockchain or distributed ledger technology is required.

Shabandri et al. [34] presented an approach using the IOTA distributed ledger technology and IoT devices to demonstrate two IoT applications on the Tangle, such as a "smart utility meter system" and a "smart car transaction system". These proposed applications were connected to the internet using low power wide area networks (LPWAN). A DAG-based blockchain IOTA was used by the researchers to overcome the scalability and transactional cost of the conventional blockchain. Although the research paper gave detailed steps to implement the proposed applications, a well-defined architecture was missing and only a proof-of-concept (PoC) was presented.

Benedict et al. [35] proposed an implementation in the cloud that uses IoT-enabled blockchain to address some existing issues in smart cities. The research focuses on the use of "chaincodes", which are also known as smart contracts, for monitoring air quality systems in smart cities. An architecture called an "IoT-enabled blockchain for an air quality monitoring system (IB-AQMS)" was proposed and an experiment to assess the model was performed. However, the "chaincode" execution time for their approach was too high and would not satisfy the current IoT demands for a scalable system.

Guanochanga et al. [36] developed a wireless sensor network that monitored several air quality parameters within smart cities. An experiment was conducted on their proposed system and excellent results were obtained in the preliminary analysis. The preliminary results showed that the proposed approach could be used as a cost-effective tool for monitoring air quality. However, the approach lacked a framework or an entity that could ensure the integrity and security of the air quality data.

Mahmoud et al. [37] presented a review on the security of the IoT, various requirements for security, and proposed different countermeasures to secure IoT devices. A detailed description of the security issues that must be addressed at each layer of the IoT architecture was explained.

Bures et al. [38] provide a comprehensive review of the various features of IoT and the security challenges specifically related to IoT. The paper covered a vast number of security features and challenges that must be addressed to secure IoT devices and emphasized that security and privacy are the major security challenges that must be addressed to achieve a secure IoT system.

Our proposed architecture, which uses the IOTA nodes, overcomes the above-mentioned limitations. The proposed model satisfies the major security requirements for IoT, which include data confidentiality, integrity, and security at the application layer of the IoT stack or where the end-user requires the data. This provides a secure working environment for monitoring environmental IoT data generated from various IoT devices. Furthermore, in this paper, we conduct an extensive experimental evaluation of our proposed model to access its performance.

#### **4. Proposed Architecture**

The proposed work in this research paper aims to provide an environmental monitoring application by using the IOTA distributed ledger and the masked authenticated messaging (MAM) protocol. This application aims to ensure the security and privacy

of the sensor data, as well as to control and prevent various environmental issues and hazards such as air pollution and greenhouse emissions. Moreover, this paper measures, analyzes, and compares the performance of the capability of MAM protocol using a nonprotocol method.

#### *4.1. Publishing and Fetching Environmental Sensor Data*

We set out to evaluate MAM's potential for publishing environmental sensor data since it is a lightweight data communication protocol over an immutable distributed ledger. Using an MAM protocol, a system that could publish and fetch the environmental sensor data was developed. We installed the MAM Client JavaScript Wrapper library [39], as well as preparing the data payloads to be published to the private Tangle using MAM, and structured the data, utilizing the JSON format in the Windows client.

The Windows client was configured to publish the MAM data payloads through a restricted channel where a channel key and authorization key are used by the data publisher, i.e., an environmentalist, to encrypt the MAM data payloads. At the transaction level, an environmentalist can define the access controls. If an environmentalist wants to give one or more environmental officers access to their channels, they can send their channel keys to them. In return, the environmental officer could retrieve and authenticate the corresponding data payloads from the Tangle. If an environmentalist would like to revoke access to their stream of data at any time, this just requires updating their MAM channel's authorization key and safely transmitting it to a desired environmental officer.

With this architecture in place, as shown in Figure 8, the client device automatically published environmental sensor data to the private Tangle using the MAM Client JavaScript Wrapper library. Using MAM's restricted channel mode, data payloads were attached. We were able to examine how an environmentalist could change controls for accessing a specific stream of messages by upgrading their authorization key. To acquire the data payloads once the transactions were published to the Tangle, we used an authorization key and channel key.

We evaluated and compared the performance of our MAM implementation with a non-protocol-based approach, to further assess MAM's capability and applicability for this functionality. We published payloads, sized 145, 330, 515, and 740 KB, in the restricted channel configuration by utilizing the MAM client JavaScript Wrapper library for Node.js on the Intel(R) CoreTM i7-8565U processor of the Windows client device. We chose these sizes of payloads due to the limitations of the MAM protocol, which can handle a maximum size of 740 KB. Keeping the sensor data payloads, the processor, and the client device the same, we published the data payloads with a non-protocol approach [40] to the private Tangle, using Python and Jupyter Notebook as the runtime environment. Furthermore, we analyzed and compared the results of the two approaches.

#### *4.2. Hashing of Merkle Tree*

Hashed trees are generated using the Merkle hashing technique, where the direction of the trees goes upward. This tree is called the Merkle hash tree (MHT), wherein the leaves of the tree represent the hash of the values of the data or the ordered elements of a set. Let this authentic ordered set of elements for MHT be *x*0,0, *x*0,1, *x*0,2, ... , *x*0,n; therefore, the leaf node of the element *x*0,*<sup>i</sup>* will be the hash of that element. Let this leaf node be represented by *x*1,*i*, where *x*1,*<sup>i</sup>* = *H*(*x*0,*i*) and *H*() is a function that is cryptographically hashed one way.

A node in the MHT contains multiple incoming edges; the value of a node is the combined or concatenated hash [41] of its preceding nodes, also known as child nodes, where the sequence of the nodes is maintained. An internal node or a non-leaf node *x*2,0 with child nodes *x*1,0 and *x*1,1 hence contains the value *x*2,0 = *H*(*x*1,0||*x*1,1). The MHT and a verification object that contains a set of nodes can be used to demonstrate the existence of an element. The root of the MHT [42] can be recomputed by the verifier by using the verification object and a set of nodes that are contained within it. The verifier compares the recomputed root using the verification object, with the publicly known root that the

tree generates. For instance, consider the element *x*0,0 in the MHT shown in Figure 9; the verification object consists of the values of the nodes *x*0,0, *x*1,1, and *x*2,1. *x*1,0 = *H*(*x*0,0), *x*2,0 = *H*(*x*1,0||*x*1,1) and conclusively, *root* = *H*(*y*2,0||*x*2,1) is constructed by the verifier. Once this verification object is constructed, the verifier can compare the computed root with the publicly known root and verify the value.

#### *4.3. Hashing, Merkle Tree Signature Scheme, and One-Time Signatures*

A digital signature technique is also known as the one-time signature (OTS) scheme can only be used to do a signature on one message with one key pair. Faster signing and algorithms for verification can be achieved with different techniques using hash-based OTS when compared to schemes such as RSA [43], which is a public-key digital signature technique. However, there are significant restrictions to OTS approaches, such as the length of signatures, the size of keys, and the maximum number of signatures possible.

**Figure 9.** A binary Merkle hash tree built for the authentic values *x*0,0, *x*0,1, *x*0,2, *x*0,3. The values of nodes required to verify *x*0,0 are bounded with broken lines.

Cryptographic secure hash functions ensure the security of OTS. The properties of a cryptographic secure hash function will be defined in this section. There are three categories, namely, "preimage-resistant", "second preimage-resistant" and "collision-resistant", and a hash function H: {0,1}\* tends to {0,1}<sup>s</sup> that is cryptographically secure if it falls in the above three categories.

• Preimage-resistant.

For a hash function H, if it is hard to find any *m* for a given *h* with *h* = *H*(*m*), then it is preimage-resistant.

• Second preimage-resistant.

For a hash function H, if it is hard to find any *m*<sup>2</sup> for a given *m*<sup>1</sup> with *H*(*m*1) = *H*(*m*2), then it is second preimage-resistant.

• Collision-resistant.

For a hash function H, if it is hard to find a pair of *m*<sup>1</sup> and *m*<sup>2</sup> with *H*(*m*1) = *H*(*m*2), then it is collision-resistant.

This multiple OTS can be verified by using a single public verification key, which is possible due to the MHT-based Merkle signature scheme (MSS). Each OTS scheme is represented by one leaf of the MHT. This implies that the same number of messages can be produced by each tree as the leaves of the MHT. The OTS technique's public verification keys [44] will be used to verify all of these communications. The OTS scheme's public verification keys are validated by computing the MHT's root from a specified verification object, as illustrated in Figure 7.

Only a limited number of messages can be signed with one public key, "pub\_key", by using MSS. Let NUM = 2n be the total possible number of messages since they must be a power of two. To generate the public key, "pub\_key", the first step is to generate the private keys *Xi* and public keys *Yi* of 2n one-time signatures. For each public key *Yi*, a hash value *<sup>H</sup>*(*Yi*) is calculated, where 1 ≤ *<sup>i</sup>* ≤ <sup>2</sup>n. An MHT is constructed with these hash values, *hi*, 2n+1 − 1 nodes, and 2<sup>n</sup> leaves. In the MSS, the public key "pub\_key" is the root of the Merkle tree.

Consider a message, M, which is to be signed with MSS [45]; first, a signature *S* results due to the signing, using a one-time signature technique on the message M. To execute the signature, S, one of the public and private key pairs (*Xi*, *Yi*) is used [46]. Let the path from a given leaf to the root be denoted by P. The total number of nodes that path P contains is *n* + 1, with paths *P*1, ... , *Pn*+1, where *P*<sup>1</sup> = *y*1, *<sup>i</sup>* is the leaf and *Pn* = *yn*+1, 0 = *pub*\_*key* is the root of the MHT. We require every child of the nodes *P*2, ... , *Pn*+<sup>1</sup> to compute *P*. As it is known that *Pi* is a child of *Pi*+1, therefore, to calculate the next node *Pi*+<sup>1</sup> of the path P, both the children of *Pi*+<sup>1</sup> must be known. To solve this computation, we require the sibling node of *Pi*. Let *si* be the sibling, such that *Pi*+<sup>1</sup> = *H*(*Pi*||*si*) in the case where *si* is odd; if it is even, then *Pi*+<sup>1</sup> = *H*(*si*||*Pi*). Therefore, *n* nodes, *s*0, ... , *sn*−<sup>1</sup> are required to compute each node present in *P*. The signature of the MSS *sig* = (*S*||*s*2||*s*3||*sn*−1) comprises the one-time signature *S* of the message M, plus the nodes.

The recipient knows the signature, *sig* = (*S*||*s*2||*s*3||*sn*−1), the message M, and the public key *pub*\_*key*. Firstly, the one-time signature *S* of message M is verified by the recipient. *P*<sup>1</sup> = *H*(*Yi*) is computed by the recipient, who hashes the public key of the one-time signature. For *k* = 1, ... , *n* − 1, the nodes of *Pk* of path *P* are calculated with *Pk* = *<sup>H</sup>*(*yk*−1||*sk*−1) if the sibling index is odd, *Pk* = *<sup>H</sup>*(*sk*−1||*yk*−1) if it is even. The signature is valid if *Pn* = *pub*\_*key* of the MSS.

#### **5. Experimental Results and Analysis**

An experiment was successfully performed that proved the feasibility of the proposed system to publish and retrieve authenticated, encrypted environmental IoT sensor data by using a distributed ledger. The MAM protocol ensured the source's validity and the data's integrity, which were formatted in the JSON format. We also demonstrated how an environmentalist might change the authentication keys to restrict permission to the data they may publish in the future. As a result, we demonstrated the potential of granular access controls, defined by the environmentalist.

A private Tangle was created, which consisted of three full nodes, called the coordinator, and two neighbor nodes, namely, "Neighbor Node\_1" and "Neighbor Node\_2" to test our proposed work, as shown in Figure 8. All three nodes were set up on three Linux Ubuntu servers with Hornet installed on them. Hornet is a powerful, community-driven IOTA node software written in the Go language and is a lightweight alternative to the IOTA reference implementation (IRI). Hornet was developed for the secure transfer of tokens or data, and for experimenting and implementing IOTA protocols between nodes or network participants. Machines can act as a node and connect to the IOTA network with the help of the Hornet software. These nodes or machines have functions such as authenticating the transactions, storing these authenticated transactions on the Tangle, and fetching these transactions back from the Tangle whenever required.

The dataset used was an open-source dataset that contained the environmental sensor data in a JSON format. The data included environmental parameters, such as temperature, timestamp, unique device id, carbon monoxide level, humidity percentage, light detected, liquified petroleum gas content, motion detected, and smoke levels. The payloads were created, and three actions (namely, create, attach, and fetch) were performed and analyzed in 300 trials. The Windows client machine, also known as the IOTA client, published and retrieved sensor data in the form of transactions to the Tangle. The client machine connects to the private Tangle using IOTA API and can make various API calls to perform various tasks. The experiment was performed with two approaches—(1) using the MAM protocol and (2) a non-protocol-based approach.

An experimental assessment was performed to evaluate the scalability of the two approaches. To achieve this, we focused on the three major tasks (i.e., create, attach, and fetch) that occur when publishing and fetching transactions. For the "create" task, we calculated the time it takes to create the transactions before publishing them to the IOTA nodes. The IOTA API was used to create the transaction object from the data payload and the execution time for this task was measured, which is called "create time".

The next step was to execute the "attach" task and calculate its execution time. Once the transaction object is created, it is published to the IOTA network by conducting the PoW and storing the transactions that the IOTA nodes perform. We calculated the execution time for this and labeled it as "attach time".

The final step was to execute the "fetch task" and calculate its execution time. After the transactions are published and stored in the IOTA network, we fetched these transactions by performing a query to the private Tangle, which in response provides the transactional data. We calculated the execution time for this fetch task and labeled it as "fetch time".

The three tasks can be mathematically expressed for the two approaches in the following way:

> *MAMc* = *E*(*data*) + *ch*\_*gen MAMa* = *PoW*(*MAMc*) + *stor*(*MAMc*) *MAMf* = *D*(*que*(*MAMa*) + *response*)

*NON*-*MAMc* = *Enc*(*data*) *NON*-*MAMa* = *PoW*(*NON*-*MAMc*) + *stor*(*NON*-*MAMc*) *NON*-*MAMc* = *que*(*NON*-*MAMc*) + *response*

where *E* represents encryption; *ch*\_*gen* represents channel generation; *stor* represents storing; *Enc* represents encoding; and *que* represents a query.

#### *5.1. MAM*

The proposed work was performed using Node.js, an open-source cross-platform runtime environment for web application development [47]. Node.js apps are written in JavaScript and operate on a variety of platforms. MAM is an IOTA protocol that ensures only the authenticated parties are sending messages that are encrypted, ensuring both confidentiality and security. We used the restricted channel mode of MAM, which encrypts the data using the channel key and authorization key; only those parties having the correct keys can access the data from the IOTA Tangle.

With this system in place, the IOTA client created, attached, and fetched the sensor data payloads by executing the JavaScript code in Node.js, using the MAM Client JavaScript Wrapper library. After the transaction was published to the Tangle, the sensor data was fetched by using the channel key along with the authorization key. The results of this approach are displayed in Table 2.


**Table 2.** Results of the MAM experiment.

#### *5.2. Non-Protocol Method*

Using this approach, we published and retrieved the data payloads from the Tangle by only publishing the sensor data in the form of zero-value transactions [48], which are transactions that only contain data and no cryptocurrency, and without using any IOTA protocol. The proposed work was performed using Jupyter Notebook [49] which

is an open-source web tool for creating and sharing documents with live code, equations, visualizations, and machine learning. Two Python scripts were written, where one script was configured to publish the sensor data, i.e., creating and attaching the transactions to the Tangle, while the other one was used to fetch the data from the Tangle. These two scripts utilized the official Python library for IOTA, called Pyota. Jupyter Notebook, running on the IOTA client, executed the two scripts to perform the abovementioned tasks.

With this system in place, the IOTA client published and fetched the sensor data from the Tangle with the help of the address whence the transactions were sent. The results of this approach are shown in Table 3.

We concentrated our investigation on the tasks that caused significant time delays for publishing and retrieving the messages. The three acts were studied: create, attach, and fetch. First, based on our findings, we discovered that the execution time for the message creation task was precise and was dependent on both the processor and the size of the payload. Second, we found that the average time for the attack process had a strong relationship with the size of the payload. Because the attaching stage involves the proof-of-work [50], which was conducted remotely by the private IOTA Tangle, a large variance and high correlation to payload size were expected. Thirdly, the average time to fetch a message from the private Tangle showed a high correlation to the payload size.

The average time was calculated for all three actions i.e., create, attach, and fetch, respectively, and are displayed in Figures 10–12. It can be seen that the MAM protocol performs far better than using any non-protocol method for publishing and retrieving sensor data from the private Tangle.


**Table 3.** Results of the non-protocol method.

#### *5.3. Discussion*

Since IoT devices are utilized in a variety of applications, there is a need to ensure data privacy and security, based on the application domain and the type of data being communicated between parties, such that an adversary cannot eavesdrop or tamper with the data.

Due to the IOTA distributed ledger, we achieved a tamper-proof audit trail of environmental sensor data, published from various IoT devices. The MAM extension module of IOTA provides environmentalists with the ability to publish, store and fetch the encrypted, authenticated, on-demand environmental sensor data by using the Tangle. The MAM protocol empowers the environmentalists by providing agency over the collected environmental sensor data, allowing them to share this data with the environmental officers for monitoring purposes. MAM's limited mode gives environmentalists fine-grained access controls over how data is shared across specialists in the digital environmental ecosystem, while the Tangle adds an extra layer of integrity to ensure that data is not tampered with. We discuss the privacy, security, and feasibility of our proposed system in the remainder of this section.

**Figure 10.** Line graph displaying the average "create time", with respect to payload size, for the MAM protocol and non-protocol methods.

**Figure 11.** Line graph displaying the average "attach time", with respect to payload size, for the MAM protocol and non-protocol methods.

Since every node in a distributed ledger's network needs a copy of the current state of the ledger, distributed ledger technology seems to go against our present understanding of digital privacy. Despite the fact that value transactions on distributed ledgers may be pseudonymous, monitoring network traffic by analyzing the frequency of transactions and locations of origin could lead to the conclusion that one person has communicated with another regularly. Moreover, finding out the number of tokens an entity possesses is also possible, with varying levels of uncertainty. On a distributed ledger, enhancing privacy while maintaining auditability is still an ongoing area of research. Nevertheless, since MAM eliminates the concept of two entities communicating with each other, this issue does not pose a difficulty for our proposed system. Instead, the issuer generates transaction addresses at random in a data stream, regardless of who has access to the information required to decrypt the data. The following along of a public or private chain of messages can be achieved by the subscribers from their point of entrance forward since

the next channel key is incorporated with the current message. Our technique, on the other hand, makes use of MAM's restricted mode, which, as mentioned in Section 2.2, allows an individual to revoke access from previous subscribers by making the addresses of future transactions unknown to them. This can be achieved only if the user changes the authorization key and, hence, access by undesired subscribers is revoked. Data can be kept private inside the transactions, due to the access controls that the MAM channel modes offer and are, thus, contradictory to the feature of transparency in distributed ledgers. If an environmentalist prefers not to have that amount of control over their data, they can generate and store authorization keys themselves, or they can delegate that power to environmental professionals with higher authority. The United States Environmental Protection Agency (US EPA) or another federal agency must store these authorization keys. Environmental officers will be allowed to access data if an environmentalist is unable to recollect them, give a log of their authorization keys, or, if the officer is needed to take immediate action, to manage an environmental threat.

**Figure 12.** Line graph displaying the average "fetch time", with respect to payload size, for the MAM protocol and non-protocol methods.

Even though we demonstrated how MAM could be used to enable secure environmental sensor data exchange, we built our framework to be flexible enough to accommodate any open environmental data exchange standards. Furthermore, data can be transmitted using MAM from any endpoint with an internet connection, such as an environmentalist's computer, a server at a government institution like the US EPA, a mobile device, or a Bluetooth low-energy sensor. Our proposed system can be effortlessly linked with any professional in the digital environmental ecosystem due to the accessibility of encrypted data through open APIs. This, we believe, will facilitate acceptance, and open the door to new uses that go beyond environmental data collected without the oversight of environmental experts.

#### **6. Conclusions and Future Directions**

This study investigated the creation of an on-demand digital environmental ecosystem that relies on algorithms to analyze a huge amount of data, as well as the requirement that this data should be immutable, authenticated, and distributed. Using the MAM protocol, we demonstrated how encrypted environmental sensor data can be broadcasted, stored, and fetched from the IOTA Tangle to prove the data's integrity, security, and privacy. We also showed how granular access controls can be defined and updated by environmentalists. The MAM protocol proved to be a useful tool for encrypting and authenticating sensor

data, although it may be improved in terms of performance and design. Many application fields, such as healthcare, the supply chain, and data storage of many kinds of sensor data, could benefit from this way of storing and delivering encrypted sensor data.

Based on the results of our extensive experimental evaluation of the proposed model, we can conclude that the MAM protocol performs better and provides better security than the non-protocol approach. The MAM protocol provided some additional features such as data encryption and granular access control, which provided better security and privacy, compared to the non-protocol method. Therefore, the MAM protocol can be seamlessly linked to various IoT devices to meet the scalability demands of these devices.

For future work, we suggest that the MAM protocol must integrate a secure and efficient key-transmitting method that would exchange the authorization keys between different entities. Additionally, as the MAM protocol develops and matures, we will demonstrate how this protocol can be used to ensure data integrity, by developing a proof-of-concept across academic universities.

Finally, we need to address how a huge dataset can be maintained across different stakeholders since the sensor data is widely distributed and the sensors are producing more data exponentially with time. IoT and embedded devices have the potential to generate massive amounts of data that will be incompatible with complete nodes, which cannot store the entire history of data. The complete nodes will keep track of the current state and prune the remaining data to make room for new transactions. An organization must have a complete record of all relevant transactions; nevertheless, the trimmed transactions will still have provable cryptographic links.

**Author Contributions:** P.G. created the proposed architecture and experimental scripts, and is the main writer. T.B. supervised the proposed model and is the secondary writer. S.J. contributed toward the writing of background technologies for this research. A.P.-P. and H.U. supervised the conducted research and reviewed the research article. Finally, L.L. provided the funding and the resources to perform this research. All authors have read and agreed to the published version of the manuscript.

**Funding:** This research was funded by the U.S Department of Energy National Energy Technology Laboratory (DOE NETL), grant number is DE-FE0031745.

**Data Availability Statement:** The dataset used for this research was publicly available and can be found here [https://www.kaggle.com/garystafford/environmental-sensor-data-132k (accessed on 20 July 2020)].

**Conflicts of Interest:** The authors declare no conflict of interest.

#### **References**


## *Review* **CNN for User Activity Detection Using Encrypted In-App Mobile Data**

**Madushi H. Pathmaperuma, Yogachandran Rahulamathavan, Safak Dogan \* and Ahmet Kondoz**

Institute for Digital Technologies, Loughborough University London, London E20 3BS, UK; o.m.h.pathmaperuma@lboro.ac.uk (M.H.P.); y.rahulamathavan@lboro.ac.uk (Y.R.); a.kondoz@lboro.ac.uk (A.K.) **\*** Correspondence: s.dogan@lboro.ac.uk

**Abstract:** In this study, a simple yet effective framework is proposed to characterize fine-grained in-app user activities performed on mobile applications using a convolutional neural network (CNN). The proposed framework uses a time window-based approach to split the activity's encrypted traffic flow into segments, so that in-app activities can be identified just by observing only a part of the activity-related encrypted traffic. In this study, matrices were constructed for each encrypted traffic flow segment. These matrices acted as input into the CNN model, allowing it to learn to differentiate previously trained (known) and previously untrained (unknown) in-app activities as well as the known in-app activity type. The proposed method extracts and selects salient features for encrypted traffic classification. This is the first-known approach proposing to filter unknown traffic with an average accuracy of 88%. Once the unknown traffic is filtered, the classification accuracy of our model would be 92%.

**Keywords:** encrypted traffic classification; network analysis; mobile data; network traffic to image

#### **Citation:** Pathmaperuma, M.H.; Rahulamathavan, Y.; Dogan, S.; Kondoz, A. CNN for User Activity Detection Using Encrypted In-App

Academic Editor: Christoph Stach

Mobile Data. *Future Internet* **2022**, *14*, 67. https://doi.org/10.3390/

Received: 17 December 2021 Accepted: 15 February 2022 Published: 21 February 2022

fi14020067

**Publisher's Note:** MDPI stays neutral with regard to jurisdictional claims in published maps and institutional affiliations.

**Copyright:** © 2022 by the authors. Licensee MDPI, Basel, Switzerland. This article is an open access article distributed under the terms and conditions of the Creative Commons Attribution (CC BY) license (https:// creativecommons.org/licenses/by/ 4.0/).

#### **1. Introduction**

In recent years, traffic classification has attracted increasing attention, as it is used in network management, security, advertising, network design, and engineering. Network traffic classification involves analyzing traffic flows and identifying the type of content within these flows. In network traffic analysis, a network trace of a device or a group of devices is taken as input and, as output, information about those devices, their users, their apps, or in-app activities is given. Network traffic classification has many possibilities to solve personal, business, internet service provider, and government network problems such as anomaly detection, quality of service control, application performance, capacity planning, traffic engineering, trend analysis, interception, and intrusion detection. To date, several traffic classifications approaches have been proposed and developed. These methods have evolved significantly over time from port-based, deep packet inspection (DPI) to machine learning (ML) methods [1]. The use of dynamic port-negotiation mechanisms by applications has made port-based methods no longer suitable. An increase in the use of encrypted internet traffic and privacy policies that prevent access to packet content have rendered relying on a packet's payload or DPI no longer effective. Most research activities that perform encrypted traffic classification rely on extracting statistical features from traffic flows, which is followed by performing feature selection to eliminate irrelevant and redundant features. They then use classical machine learning algorithms, such as random forest (RF) [2,3], Bayes net [4], K-nearest neighbors (KNNs), and support vector machine (SVM) [5] to perform the classification. These methods can handle both encrypted and unencrypted traffic. However, the performance of these methods greatly relies on human-engineered features, which limit their generalizability [1].

CNNs, an important model of deep learning (DL), were initially applied in the field of image recognition [6] and achieved remarkable results. With the advances in DL, the use of CNNs has become prevalent in many fields such as speech recognition, audio processing, visual document analysis, genomics, and in medical use [7]. Yet, it has not been sufficiently utilized in network traffic classification [6]. This paper proposes an image-based method that represents network traffic as images and utilizes DL architecture based on CNNs to learn the traffic features in these images and perform traffic classification. This research focused on conducting network traffic classification to identify user activities performed on mobile applications (known as in-app activities) from a sniffed encrypted internet traffic stream. Figure 1 shows the generated images using encrypted in-app activity data for three different in-app activities. The main advantage of using a CNN in image classification is that there is no need to extract features beforehand, because the CNN model can learn features by itself.

**Figure 1.** Grayscale images generated from the encrypted in-app activity data.

In this research, sensitive information related to online users, such as the activities performed with their mobile apps, are inferred by passively sniffing encrypted wireless network traffic. Even though encryption protocols are used to encrypt data, it protects only the packet's payload, but it does not hide *side channel data* such as frame length, data length, inter arrival time, and direction (incoming/outgoing). Therefore, in this research, the side channel data were used to reveal private information related to the user's online behavior. Users perform different activities using the apps installed on their mobile devices. Each in-app activity has a distinct network behavior [8] and, thus, generates different traffic flows. Traffic flow data are converted into images and image classification deep learning techniques are used to detect in-app activities.

The contributions of this paper are summarized as follows:


fine-grained in-app activities. For example, when a generic Facebook activity "posting on wall" is considered, the model can determine whether the post is an image, a long text, a short text, a video, or a check-in. This level of fine-grained analysis is challenging, as classification is performed in an encrypted domain using only side channel data;

(d) Novel data set for future research: A comprehensive data set was created by performing a series of actions on eight apps, namely, Facebook, Instagram, WhatsApp, Viber, Messenger, Gmail, Skype, and YouTube. This data set will be shared openly with the research community to foster new studies and allow reproduction of the results presented. (https://www.dropbox.com/s/9tihcj9wx2sia1t/Dataset.7z?dl=0 (accessed on 4 October 2021))

The rest of this paper is organized as follows: In Section 2, the related work is reviewed. Section 3 describes the methodology of the proposed classification system. Section 4 presents the experimental results and discussions. Section 5 provides concluding remarks.

#### **2. Related Work**

In the literature, two types of research methods have dominated traffic classification: statistical methods and neural networks.

Statistical classification is a technique that exploits the statistical characteristics of network traffic flow to perform traffic classification. Features, such as packet length, packet duration, packet inter-arrival time, and traffic flow idle time, are used in this method. To perform an actual classification based on statistical features, classifiers, specifically ML algorithms, are used. Conti et al. [9] performed mobile user actions classification based on packet sizes and their order. Saltaformaggio et al. [5] developed NetScope to detect user activities based on inspecting statistical features obtained from internet protocol (IP) headers. Taylor et al. [2,10] used features, such as packet lengths and statistical properties of flows, to train support vector classifier (SVCs) and random forest classifiers to perform mobile app classification. Pathmaperuma et al. [4] identified user activities performed on mobile apps using statistical features generated from frame length, inter-arrival time, and direction leaked from encrypted traffic. Wang et al. [3] computed 20 statistical features from frame size and inter-arrival time to train an RF classifier to perform app identification. Zhang et al. [11] proposed a scheme by combining supervised and unsupervised machine learning techniques to classify apps. Twenty unidirectional flow statistical features related to packet size, packets, inter-packet time, and bytes were extracted and used to train the proposed classifier. A classification method was proposed by Draper-Gil et al. [12] with only time-related flow features on both regular encrypted traffic and protocol encapsulated traffic.

Many works have applied neural networks in network traffic analysis such as malware classification [13], anomaly detection [14], DDoS attacks detection [15], and intrusion detection [16,17]. In [18], Wang et al. proposed an end-to-end encrypted traffic classification approach with 1D CNN to detect traffic types such as streaming, VoIP, and file transfer. Lopez-Martin et al. [19] proposed using a recurrent neural network (RNN) combined with a CNN for IoT traffic classification. In [20], Aceto et al. performed traffic classification in encrypted network flow using DL techniques. Wang [21] proposed a stacked auto encoder (SAE)-based method to detect network protocols. The results showed that Wang's approach worked well on the applications of feature learning, protocol classification, anomalous protocol detection, and unknown protocol identification. In [22], Lotfollahi et al. proposed a framework to perform traffic characterization and application identification using DL, embedding an SAE and CNN to classify network traffic.

Recent studies have explored the use of CNNs to perform classification by converting network traffic flows into images. Wang et al. [13] converted traffic to 2D images and then applied 2D CNN to classify the traffic images achieving the goal of malware classification. Ma et al. [8] proposed a CNN model that predicts large-scale, network-wide traffic speed. In this work, spatiotemporal traffic dynamics were converted to images describing the time and space relations of traffic flow via a 2D time–space matrix. Zhou et al. [6] proposed a

classification algorithm Min–Max Normalization (MMN) CNN that processes traffic data and maps them into gray images that are input into a CNN to detect 12 types of traffic categories such as mail, game, and multimedia. Tavakoli [23] presented the Seq2Image method to perform human genomic sequence classification converting genome sequences to images and then using a 2D CNN to classify the created images of sequences. Shapira et al. [7] presented the FlowPic approach to transform flow data into an image and then used image classification DL techniques, a CNN, to identify the flow category and application in use. Kim et al. [24–26] presented the NetViewer approach that detects and visualizes attacks and anomalous traffic by passively monitoring packet headers. In these works, multiple pieces of traffic data are represented as different colors of an image. Image processing techniques are applied to generated images to analyze the network traffic. He et al. [27] proposed an image-based method that converts the first few non-zero payload sizes of session to gray images and uses a 1D CNN to perform the classification.

The works in the literature primarily focus on classifying previously trained traffic, while none has considered performing network traffic analysis accurately in the presence of noise generated by unknown traffic, even though this would be a typical situation in a real-world scenario. Thus, this work aimed to advance the state-of-the-art by identifying previously trained fine-grained in-app activities accurately as well as by detecting and classifying previously untrained in-app activities as unknown data.

To detect unknown in-app activities, the function needs to reject the classification label for those inputs belonging to classes never exposed during training. An outputbased rejection technique is proposed in this work that leverages additional information from the deep learning model output such as the SoftMax probabilities of each class. Usually in classification tasks, the neuron with the highest probability will be chosen and the corresponding class label is assigned. In this work, a two-stage approach was used to check if the neuron with the highest probability satisfied a pre-set threshold value. Based on this, the known and unknown instances were classified. However, setting this threshold is challenging, as setting it too high increases false negatives, whereas setting it too low increases false positives. To test the impact of the threshold value on the model's performance, a range of threshold values were selected, and tests were performed.

#### **3. Proposed Methodology**

This paper proposes a CNN-based method that transfers network traffic flows into images to identify in-app activities while detecting unknown data. The method contains two main procedures. The first is to convert network traffic into images that represent side channel data of a network flow as a 2D image. The second is to apply image classification DL techniques to the generated images and perform traffic classification of previously trained and untrained apps' traffic flows.

#### *3.1. Data Collection*

For this research, a data set was created that consisted of network traffic from in-app activities of eight popular mobile apps, namely, Facebook, Instagram, YouTube, Viber, WhatsApp, Gmail, Skype, and Messenger. To obtain the ground truth, network traffic generated after executing each activity was collected separately, and the network trace was labeled with the name of the activity performed. Each app was run separately, thus limiting the presence of background traffic. To generate a sufficient number of traffic flows for inference, each activity was repeated four times and captured traffic was saved as .pcap files. The number of in-app activities considered in each app and number of samples obtained after segmenting the traffic into 1, 0.5, 0.2, and 0.1 s time intervals are presented in Table 1. The 92 in-app activities considered in this research are given in Appendix A.

We monitored the network passively and traffic was captured without connecting to the wireless network to which the target user's mobile device was connected. The traffic transmitting within the wireless network was sniffed using Airmon-ng and Airodump-ng sniffing tools from the Aircrack-ng suite [28]. Default setting of network adapters allow only to capture packets that are sent to them. To capture all traffic, we set the network adapter to its monitor mode. The experimental testbed used to sniff traffic is shown in Figure 2. The internet access to the smartphone was provided over a wireless connection via a router. The smartphone was connected to the wireless network exclusively to avoid interference from other sources. The network adapter (Alfa AWUS036NHA) was plugged to the laptop (Toshiba PORTEGE Z30-C), which was used to capture the network traffic.


**Table 1.** Features of the collected data set.

**Figure 2.** Experimental testbed for data collection.

#### *3.2. Network Traffic to Image*

Pre-processing needed to be applied on the captured traffic flows prior to mapping traffic data into images. The following pre-processing steps were performed on the obtained data set in this work.

(a) Sanitization

The three main frame types used in WLAN (IEEE 802.11) are data, control, and management frames. Only the data frames are used for data transmission. The presence of the other two types may hinder the process of analysis; therefore, the control and management frames were eliminated, and only data frames were processed further. There were data frames that did not carry data. Keeping these frames would cause bias in training the CNN [29]. Therefore, null data frames were also eliminated at this stage.

#### (b) Normalization

Normalization is an important step in data pre-processing to avoid having different scales of feature vectors and, thus, improves integrity of data. The data set contained feature values in different scales that may lead to obtaining biased results. To normalize the feature values, the standard scaler [30] was used, which normalizes each feature by removing its mean and scaling to unit variance. This equalizes the importance of all features and allows DL methods to converge faster. For each original value X with a mean μ and standard deviation σ, its normalized value X' can be determined from (1):

$$
\lambda' = (\lambda - \mu) / \sigma \tag{1}
$$

#### (c) Segmentation

During in-app activity detection, it is not possible to guarantee that the entire transaction of an activity can be observed. There can be situations where the eavesdropper starts to capture the traffic while the user is already performing an activity. In these instances, the eavesdropper can capture only a part of the traffic flow instead of the entire flow transaction. To perform in-app activity detection even by observing only a part of an activity related traffic, time windows are used to divide the traffic flows into segments. A thorough analysis of the sensitivity of this approach was performed by conducting experiments with different time window sizes: 1, 0.5, 0.2, and 0.1 s as discussed in Section 4.1.

Following network traffic pre-processing, each segmented traffic sample was converted into an image, where features and corresponding feature values were represented by pixels and pixel intensities, respectively. In this work two sets of data images were generated that used different color schemes. These were grayscale and red, green, and blue (RGB). If the segmented traffic sample, *S*, has *n* number of frames and *m* number of data values, then the value of *m*th data at *n*th frame can be represented as *Anm*. The segment *S* is represented as matrix (2):

$$S = \begin{bmatrix} A\_{11} & \cdots & A\_{1m} \\ \vdots & \ddots & \vdots \\ A\_{n1} & \cdots & A\_{nm} \end{bmatrix} \tag{2}$$

The three main side channel data considered in this work were frame length, data length, and inter arrival time. Segment S comprised values of these side channel data. Based on these data, individual vectors were created. The division can be expressed as matrix (3):

$$\mathbf{X}\_{\text{i}} = \begin{bmatrix} \mathbf{A}\_{1\text{i}} \; \mathbf{A}\_{2\text{i}} \; \dots \; \mathbf{A}\_{\text{ni}} \end{bmatrix} \tag{3}$$

where n is the number of frames and Xi represents all data values of the ith side channel data. The number of vectors that are created depends on the number of side channel data. In this research, three side channel data were considered; thus, three vectors were created. When employing a grayscale model, these three vectors combined to form one vector. Whereas in the RGB model, these were passed together as three separate vectors.

If the image size is very small, then it cannot be sent through the required number of convolutional layers, because after each layer, the size is reduced. Therefore, resizing was applied to match with the respective pre-defined input image size.

Each element in the matrix is treated as a pixel with the grayscale value of the pixel, where the color intensity is proportional to the matrix value. Figure 1 shows three in-app activities' traffic flows in grayscale format. The input image dimensions were h × w × c, where h × w were the dimensions of the image, and c was the number of channels. The image dimension wass constructed according to the number of features in the data set. The dimensions of the images were set to 28 × 28 following empirical tests. Grayscale images had one channel. Hence, the input image size of grayscale images was resized to 28 × 28 × 1 (784). Data fed into CNN must be uniform. The data that were less than these pre-defined image sizes were zero-padded, and data that were more than the pre-defined image sizes were truncated to match the respective pre-defined size.

#### *3.3. Image Classification Using CNN*

The CNN architecture proposed to identify in-app activities was composed of four main parts: model input, traffic feature extraction, prediction, and model output as shown in Figure 3.

**Figure 3.** Proposed CNN architecture to identify in-app activities. The traffic flow data transferred into pixelized images are used as the input to the CNN model with input dimension of 28 × 28.

The input layer was then connected to a combination of convolution and pooling layers to learn image features. In this proposed architecture, three convolutional layers were used, where each convolution layer was followed by a pooling layer that selects the most important features from its receptive region and reduces the number of parameters required to train the model. Pooling layers reduce the size of the output through the convolutional process and cancel noise. In our model, the max-pooling function was used, which outputs the maximum value in a rectangular neighborhood of the previous layer.

The fully connected layers at the end of CNN concatenated the output of the convolution layer into a dense vector. This was passed to the model prediction phase.

The dense vector was then transformed into model outputs through a fully connected layer, which had 92 outputs indicating the number of classes (in-app activities) used to classify the input images. This output layer was a SoftMax layer, which output a Kdimensional probability distribution vector of values in the range of 0–1, where K is the number of classes (K = 92). Each node value represents a class score. The class with the highest score was selected and the corresponding class label was assigned.

The hyperparameters, such as the number of convolutional layers, number of fully connected layers, number of filters for each hidden layer, filter and stride size, and activation functions, were selected through comprehensive tests involving numerous parameter combinations. The depth of the CNN should be neither too large nor too small [31], and thus it is able to learn complex relations while maintaining model's convergence. To determine the suitable value for the model's depth, different values from small to large were assigned to test the CNN model until the best model was found. The rationale behind using this architecture was based on the experiments we conducted in which we discovered that this architecture was the best fit model for our problem.

#### *3.4. Unknown In-App Data Detection*

In a real-world setting, data traffic captured contains both previously known and unknown traffic flows. Previously known traffic is related to the in-app activities considered during model training whereas unknown traffic relates to the in-app activities not considered during model training. A major challenge to the robustness of the classifier's performance comes from previously unknown/unseen traffic. Identifying previously untrained in-app activities using the proposed method is one of the key contributions of this work.

When the traffic flows are converted into images and input to the CNN model, they pass through hidden layers and reach the output layer. A SoftMax layer is added to the end of the CNN, which converts the output values into a probability distribution. Model's output layer has nodes that is equal to the number of classes. The SoftMax layer provides probabilities for each class label in the interval (0, 1). Usually for a given input sample, one of the classes will have a higher probability value than the rest of the classes. In normal traffic classification tasks, a class is assigned to a data point based on the highest probability. However, in this work instead of making the class with the highest probability be the final classification, a threshold approach is used to determine if the test sample is a known or unknown instance. Figure 4 shows the technique used to detect noise (unknown in-app data) generated by previously unknown traffic. *Pmax* denotes the node with the highest predicted class probability. The decision for converting the predicted probability into a class label is dominated by a parameter known as the *threshold*. If *Pmax* < *threshold*, then the test sample is labeled as an unknown instance. Threshold set on a positive class determines whether the test sample belongs to one of the trained classes, which translates into a pre-trained in-app activity or not.

**Figure 4.** Framework to detect unknown in-app activity data.

To examine the impact of the threshold on model's performance, a range of threshold values were selected and tested. Setting a threshold too high results in an increase in false negatives, while setting it too low leads to an increase in false positive. Therefore, setting a balanced threshold value is challenging. In this work, a threshold value that contributes to achieving the highest classification accuracy was utilized, which was obtained empirically as 0.97.

#### **4. Experimental Results and Discussion**

The performance evaluation of the proposed model is presented in this section. When evaluating the proposed model, the following two factors are considered to measure the performance.


The CNN models were constructed, trained, and tested by Keras 2.5.0 with TensorFlow 2.5.0 running at the back end. Experiments were conducted using 92 in-app activities from the Facebook, Instagram, YouTube, Viber, WhatsApp, Gmail, Skype and Messenger apps (see Table 1). Eighty percent of the total samples were dedicated for training, and remaining 20% for validation.

Accuracy was used to evaluate the model performance, which is computed as follows:

$$\text{Accuracy of known data} = \frac{\text{True Positives + True Negatives}}{\text{Total no. of known instances}} \tag{4}$$

$$\text{! } \qquad \qquad \qquad \qquad \text{True Negatives} \tag{5}$$

$$\text{Accuracy of unknown data} = \frac{\text{True Negatives}}{\text{Total no. of unknown instances}} \tag{5}$$

#### *4.1. Model Analysis*

The proposed CNN architecture comprises of seven layers excluding the input and output layers (as depicted in Figure 3). The three convolutional layers had 256, 128, and 64 numbers of filters in each layer, respectively. The fully connected layer had 128 nodes. Tanh activation function is applied to the output of every convolutional and fully connected layer. To reduce overfitting, the dropout technique is used to prevent complex co-adaptations on the training data [7]. In this architecture, the Adam optimizer and categorical cross entropy loss function were used.

The model performance varied with different image sizes as inputs according to our tests. When the image size was too small, there was a sign of learning degradation. When the image size was too large, then the extraction phase took much longer time. Thus, we selected 28 × 28 pixel image size, which helped to reduce the run-time and memory consumption while improving detection rate in all our experiments.

In addition to grayscale images, RGB images were also created from the collected network traffic data set. This was done to observe the performance of in-app activity classification when in-app data is converted to 3D images. Instead of considering the entire flow of an activity, we used the segment-based approach to perform the classification. Four different time windows were used to divide the traffic flows into segments: 1 s, 0.5 s, 0.2 s, and 0.1 s. Table 2 presents the training and validation accuracies, and time needed to train and test the models.


**Table 2.** Classification performance of grayscale and RGB models.

From the experimental results, it can be observed that the accuracy values obtained for the grayscale models are higher than those recorded for the RGB models for all time windows tested. This is because RGB models suffer from overfitting due to the presence of large number of features resulting from the three color channels. Therefore, grayscale images are selected as inputs to avoid false classification and complexities for the rest of the experiments.

Validation accuracy was highest when the time window size was 0.2 s. The reason is when traffic traces are segmented into a smaller window size, we were able to obtain plenty of samples. Training the model with large of samples contributed positively towards the classification accuracy. However, this was not true when the window size was further reduced. Even though the sample size increased when traffic traces were segmented into a smaller window size such as 0.1 s, the classification accuracy decreased. This was because the number of frames contained in such smaller window segments is less. When frames were considered individually or when the number of frames was insignificant, they contained very little information to perform the classification.

With the decrease in window size, leading to an increase in the number of samples, the results present that long times are needed to pre-process, train, and test the models. From the Table 2 data, it can be observed that all grayscale models achieved an average accuracy of 87%. This shows that the proposed model can identify fine-grained in-app activities even by observing only a small subset of an activity's traffic.

#### *4.2. Unknown In-App Data (Noise) Detection*

In noise detection tests we use leave-one-out approach where two data sets were created, namely training and noise data sets. From the eight apps considered in the experiments, each time an app was singled out and used to create the noise data set. The remaining seven apps were used to create the train data set. While the training data set was used to train the model, the noise data set (with in-app activities unknown to the trained model) was input to the trained model to determine its ability to detect unknown data. The result of this experiment is shown in Figure 5.

**Figure 5.** Noise detection rates of unknown apps.

In Figure 5, F, I, G, M, S, V, W, and Y denote Facebook, Instagram, Gmail, Messenger, Skype, Viber, WhatsApp, and YouTube, respectively. On each vertical bar in Figure 5, the apps used to train the model at each instance are denoted. The app labelled on the X axis is the app in the noise data set.

Let's us explain how to interpret Figure 5. The first vertical bar in Figure 5 shows that a CNN model is trained with the in-app activity data from the following 7 apps: I, G, M, S, V, W and Y. The in-app activity data from F is kept away from the training process. During the testing, the in-app activity data from F is used to determine the robustness of trained CNN model. As shown in the first bar in Figure 5, the trained CNN model successfully identified more than 90% of the in-app data from F as unknown data.

As shown in Figure 5, the proposed method achieved 75% or more in detecting noise with average accuracy of 88%. Data from Gmail and Viber applications were detected with 94% accuracy. However, the proposed model couldn't distinguish data from Skype with the trained data only 75% of the Skype traffic got correctly detected as unknown traffic. The remining 25% was misclassified as in-app activities that belong to the training data set.

To understand the nature of the misclassified traffic, further analysis was performed on the apps to which the unknown traffic got classified. The results are presented in Figure 6 in percentage values (%). For example, only 8% of the data from F is classified as known data (see first bar in Figure 5). The distribution of this 8% of the misclassified data from F is shown in the first row in Figure 6. Majority of this data (35%) are assigned to S (Skype).


**Figure 6.** Confusion matrix (% values).

Looking at Figure 6, the majority of the misclassified data was assigned to Facebook. We observed that there was a high correlation among all the considered apps with Facebook, which contributed to the misclassification. For Instagram, Gmail, Messenger, Viber, and WhatsApp, the second and third highest misclassifications came from Skype and YouTube, respectively. This can also be seen by plotting the correlation between these apps (see Figure 7).

**Figure 7.** Correlations among different apps. (**a**) correlation of Facebook with Instagram, Messenger, Skype and YouTube. (**b**) correlation of Skype vs YouTube and Instagram with YouTube and Skype. (**c**) correlation of WhatsApp with Viber and Gmail.

Figure 7a shows the correlation plots of Facebook with four different apps. Figure 7b shows the correlation plots of Skype and YouTube with two different apps. In Figure 7a,b the points are closely packed, which means the strength of the correlation was high. Apps that are highly correlated with each other have similar in-app activities with similar behavior.

Looking at the W column in Figure 5, the least amount of misclassification resulted from WhatsApp, which was 1% for all the test apps. This was due to the least correlation between W and other apps as shown in Figure 7c. It can be observed that the points are distributed loosely which means the considered apps are only slightly correlated to each other. The behavior of Facebook, Instagram, Gmail, Messenger, Skype, Viber, and YouTube in-app activities was not similar to WhatsApp's in-app activities, which makes them less correlated to each other.

To obtain a better insight into the misclassifications occurred, further analysis of the in-app activities to which the test apps got misclassified was conducted. Table 3 lists the six in-app activities with the highest misclassification percentage against each of the test apps, where the in-app activities were coded as follows:

Utuv—uploading a video on YouTube; Skvc—having a video call on Skype; Msgac—having an audio call on Messenger; Skv—sending a video on Skype; Indvc—having a video chat on Instagram Direct; Fblive—uploading a live video on Facebook; Skac—having an audio call on Skype; Fbpv—posting a video on Facebook wall Utwv—watching a video on YouTube.

**Table 3.** Misclassified in-app activities with misclassification percentage (%) values.


The highest percentage of misclassification was recorded from Utuv on Facebook and Skype. When Facebook was input to the model as the unknown/noise app, 27% of its traffic was misclassified as Utuv. When creating the Facebook data set, activities such as posting a video on wall, uploading a live video were considered, which are very similar to Utuv on YouTube. Therefore, having such similarity in the in-app activities caused the misclassification. When Skype was considered as the unknown app, 26% of its traffic was also misclassified as Utuv. Similarly, when creating the Skype data set activities such as sending a video message, engaging in a video call were considered. Again, having such similar in-app activities to Utuv has caused the reported misclassification.

While most of the Facebook traffic was misclassified as Utuv, which is in fact an activity from YouTube; most of the YouTube traffic got misclassified as Fblive, an activity from Facebook. Both Utuv and Fblive activities are related to video uploading and thus have a high correlation between each other due to their similarity in behaviour, resulting in the misclassification.

#### *4.3. Performance Comparison*

Even though in this work a CNN model was used to perform the traffic classifications, other types of neural networks could also be employed for this purpose, such as a Deep Neural Network (DNN). This section reports on the performance comparison between the DNN and CNN models when they are used in our tests.

In both models, the output types were in-app activities. But the format of the input was different: in CNN, images were provided as the input whereas in DNN, statistical features related to the traffic flows constituted the input. Although the same data set was used for both DNN and CNN models to perform tests, we employed the network architecture that resulted in the highest accuracy for each model instead of using the same network architecture across the board for a fair comparison. This was needed as the input format was different in both cases, which had a direct influence on accuracy performance. For CNN, the network architecture proposed in Section 4.1 was used. For the DNN model, four hidden layers were used with 1024, 512, 256 and 128 nodes in each layer. Tanh activation function was used for all layers expect for the output layer which used the SoftMax layer. The 48 statistical features used in [4] were utilized as the input of DNN. Figure 8 shows the training and validation accuracies obtained at 0.5 s and 0.2 s time window sizes when both models were used to perform in-app activity classification.

**Figure 8.** Accuracy comparison of the CNN and DNN models.

From Figure 8, it is noted that the DNN model has recorded the highest accuracy values compared to the CNN model in all categories. But when looked closely at the comparison at each time window size, the difference in accuracy values is maximum 5%. Significantly, all the accuracies of the CNN model are at 88% or above. Therefore, it can be concluded that both models can accurately detect previously trained in-app activities.

To compare the detection of unknown in-app data, it can be observed from Figure 9 that the CNN model has outperformed the DNN model at all the instances when different noise test traffic data sets (Test app) were applied. In both models, Gmail and Viber reported the highest noise detection rates. Compared to the DNN model, when the CNN model is employed, there is an increment of 19%, 18%, and 12% noise detection rates when YouTube, Messenger, and Skype are input as test app, respectively.

Even though the ability to detect previously trained in-app activities correctly by the CNN model is slightly weaker than that of DNN, its ability to detect previously untrained/unknown in-app activities as noise data is much stronger than that of DNN. Therefore, when the overall performance is considered, the proposed CNN model outperforms DNN. This is because when traffic flows are converted to images, the model can apply image processing techniques to reveal interesting properties of the traffic. As such, applying the proposed CNN model on the input traffic images allows for extracting and selecting salient features that enable the model to learn to differentiate trained and unknown traffic.

**Figure 9.** Noise detection comparison of the CNN and DNN models.

#### **5. Conclusions**

In this paper, a novel approach was introduced for encrypted Internet traffic classification, both for identifying known and unknown traffic and categorizing in-app activity type, based only on frame's size and time related information. User actions identified through analysing network traffic can be used in forensic investigations and security incident analysis, to improve correlation of events. Profiling users based on their in-app activities is also useful for marketing or intelligence purposes. Deep Learning obviates the need to select features by a domain expert as it automatically selects features through training, making it a desirable approach when new classes constantly emerge, and patterns of old classes evolve. Performance of the proposed CNN based method that learns traffic as images was compared with DNN that uses statistical features. The results demonstrate that the proposed CNN model has outperformed DNN when overall performance is considered. Moreover, a windowing approach was used to perform classification by observing a short time window of a flow instead of the entire session. Even though this is significantly a harder task as there is less information in partial encrypted traffic flow compared to the entire flow, our model was able to identify in-app activities with an accuracy of 92% even by observing the traffic only for 0.2 s. The novel approach of using a threshold on the confidence values exploits the model's output layer to identify in-app activities while removing noise traffic generated by untrained in-app activities with an average accuracy of 88%.

**Author Contributions:** Conceptualization, M.H.P., Y.R., S.D. and A.K.; methodology, M.H.P., Y.R. and S.D.; software, M.H.P.; validation, M.H.P.; formal analysis, M.H.P.; investigation, M.H.P., Y.R. and S.D.; data curation M.H.P.; writing—original draft preparation M.H.P.; writing—review and editing, Y.R. and S.D.; visualization, M.H.P.; supervision, Y.R., S.D. and A.K. All authors have read and agreed to the published version of the manuscript.

**Funding:** This research received no external funding.

**Data Availability Statement:** This data set is shared openly with the research community to foster new studies and allow reproduction of the results presented. (https://www.dropbox.com/s/9tihcj9 wx2sia1t/Dataset.7z?dl=0 (accessed on 10 December 2021)).

**Acknowledgments:** Madushi H. Pathmaperuma would like to express her thanks to the Loughborough University, UK, for supporting her research. Safak Dogan would like to acknowledge the Engineering and Physical Sciences Research Council (EPSRC), UK, for their support of his work (EP/W00366X/1).

**Conflicts of Interest:** The authors declare no conflict of interest.

#### **Appendix A**


**Table A1.** The 92 in-app activities considered in this research.

**Table A1.** *Cont*.


#### **References**


## *Review* **A Review of Blockchain Technology Applications in Ambient Assisted Living**

**Alexandru-Ioan Florea, Ionut Anghel \* and Tudor Cioara**

Computer Science Department, Technical University of Cluj-Napoca, Memorandumului 28, 400114 Cluj-Napoca, Romania; alexandru.florea@staff.utcluj.ro (A.-I.F.); tudor.cioara@cs.utcluj.ro (T.C.) **\*** Correspondence: ionut.anghel@cs.utcluj.ro

**Abstract:** The adoption of remote assisted care was accelerated by the COVID-19 pandemic. This type of system acquires data from various sensors, runs analytics to understand people's activities, behavior, and living problems, and disseminates information with healthcare stakeholders to support timely follow-up and intervention. Blockchain technology may offer good technical solutions for tackling Internet of Things monitoring, data management, interventions, and privacy concerns in ambient assisted living applications. Even though the integration of blockchain technology with assisted care is still at the beginning, it has the potential to change the health and care processes through a secure transfer of patient data, better integration of care services, or by increasing coordination and awareness across the continuum of care. The motivation of this paper is to systematically review and organize these elements according to the main problems addressed. To the best of our knowledge, there are no studies conducted that address the solutions for integrating blockchain technology with ambient assisted living systems. To conduct the review, we have followed the Preferred Reporting Items for Systematic Reviews and Meta-Analyses (PRISMA) methodology with clear criteria for including and excluding papers, allowing the reader to effortlessly gain insights into the current state-of-the-art research in the field. The results highlight the advantages and open issues that would require increased attention from the research community in the coming years. As for directions for further research, we have identified data sharing and integration of care paths with blockchain, storage, and transactional costs, personalization of data disclosure paths, interoperability with legacy care systems, legal issues, and digital rights management.

**Keywords:** ambient assisted living; blockchain; security and privacy; IoT blockchain integration; decentralization

#### **1. Introduction**

Ambient assisted living (AAL) is a research field that aims to bring smartness to our everyday environments by acquiring data from various sensors, understanding people's activities, behavior, and living problems, and deciding on proactive interventions to support the management of identified issues (see Figure 1) [1]. With the advance in sensing technologies and the prevalence of miniaturized, affordable Internet of Things (IoT) sensor applications have been developed to improve the beneficiary's quality of life and support personalized care [2]. A wider range of proof of concept applications for various use scenarios along with associated technologies can be found in the literature, such as fall detection systems [3], cognitive decline management [4], personalized care [5], remote follow-up [6], nutrition management [7], medication review [8] and well-being management [9].

Having more IoT devices and sensors associated with living environments leads to collecting patient data that must be shared among multiple parties on different sides [10]: validators, processors, healthcare stakeholders, etc. Nowadays, the ambient assisted living systems move the data collected in cloud systems (see Figure 1), where the potentially unlimited computation resources help in dealing with analytics and decision making [11].

**Citation:** Florea, A.-I.; Anghel, I.; Cioara, T. A Review of Blockchain Technology Applications in Ambient Assisted Living. *Future Internet* **2022**, *14*, 150. https://doi.org/10.3390/ fi14050150

Academic Editor: Christoph Stach

Received: 19 April 2022 Accepted: 11 May 2022 Published: 12 May 2022

**Publisher's Note:** MDPI stays neutral with regard to jurisdictional claims in published maps and institutional affiliations.

**Copyright:** © 2022 by the authors. Licensee MDPI, Basel, Switzerland. This article is an open access article distributed under the terms and conditions of the Creative Commons Attribution (CC BY) license (https:// creativecommons.org/licenses/by/ 4.0/).

Using decentralized distributed ledger solutions will allow multiple nodes to host the same set of encrypted data in multiple care systems that are hosted in different places and kept up to date with the actual state and data of the system [12]. Additionally, most of the collected data are rather sensitive and personal data of vulnerable people; thus, security and privacy have always been issues to deal with [13]. They constitute a barrier between vulnerable people and assistive technologies and prevent the adoption and good use of existing software solutions in the field [14]. People may become digitally vulnerable as data theft, fraud, and the unauthorized use of personal, medical, and financial information are often not even known by the victims [15].

**Figure 1.** Conceptual architecture of a cloud-based AAL system.

The privacy and security problems are critical for data-driven assisted living applications and IoT networks such as the Internet of Medical Things [14]. Data ownership and elimination of potential breaches are objectives for keeping the data, and the system secured [16]. However, because of the lack of precise specifications, even ordinary procedures might result in security breaches [17]. There is a strong need to make such applications transparent, immutable, and distributed [18]. In general, in the discussions concerning privacy and security, how consumers understand privacy is key [19]. People are more inclined to value decentralized solutions for their capacity to safeguard their privacy goals [20]. On top of technical privacy issues, lately, personal details (i.e., used to identify a person) have become one of the most valuable commodities [21]. This information might be as basic as a name or identification number, or it can be more sensitive, such as medical or behavioral data [22]. As the world becomes more digitized, internet activity is increasingly recorded, often without the user's knowledge or agreement, constituting a barrier to ambient technologies adoption.

Blockchain technology is seen as a good solution for tackling IoT monitoring, data management, interventions, and privacy concerns [23] in ambient assisted living applications [24]. Stakeholders from the ambient assisted and care fields are interested in integrating blockchain technologies into their systems to benefit from improved security, privacy, and data ownership (see Figure 2) [24]. Conventional ambient assisted living solutions use centralized cloud-based models focused on structuring data rather than privacy, ownership, and decentralization. The adoption of blockchain technology can change this landscape [25]. In a blockchain-driven assistive living application, the users will join a blockchain network, and asymmetric encryption solutions will enforce the security of data sharing [26]. The IoT devices deployed in the user environment can be joined with

smart contracts to automatically generate and sign transactions and forward them to the blockchain to be stored immutably [27]. The generated transactions are aggregated in blocks disseminated in the network and will be mined in the future blocks. To change a value in a block, the entire history of previously linked blocks needs to be rehashed, requiring a lot of computational power not being feasible these days [28]. To prove the ownership of the data, the IoT device provides a signature of the transaction, which is also useful for authentication and validation [29]. The updates are stored in chained blocks, taking advantage of the technology's properties such as reliability, availability, immutability, and consensus [30]. The blockchain enforces the provenance of data by a linked list of nodes; thus, data can be traced back by iteration of the chain [31]. In addition, securely storing the sensor's data and respecting the personal data regulations is difficult considering the perspective of the domain [32]. So, using a decentralized, user-centric approach regarding data privacy can address security and data ownership problems in developing ambient assisted living applications.

**Figure 2.** Features of blockchain technology desired for an ambient assisted living system.

Even though the research field is still at the beginning, relevant studies in the literature can be found. The motivation of this paper is to systematically review and organize them according to the research problems they address. To the best of our knowledge, there are no reviews conducted on solutions for integrating blockchain technology with ambient assisted living systems. To conduct this review, we have defined a search methodology with clear criteria for including or excluding papers, set up a reference interval, and focused on current important databases. We have included in the survey 87 papers on blockchain and ambient assisted living systems that were reviewed and organized. Thus, a reader would effortlessly gain insights into the current state-of-the-art research in the field. Nevertheless, there are still many gaps and open issues that would require increased attention from the research community in the coming years, such as data sharing and integration of care paths with blockchain, storage, and transactional costs, personalization of data disclosure paths, interoperability with legacy systems, legal issues, digital rights management, etc.

The remainder of the article is organized following the Introduction, Methods, Results, and Discussion (IMRAD) structure: Section 2 presents the methodology and methods used in conducting the literature review; Section 3 illustrates the results by describing and organizing the most relevant research works; Section 4 presents a discussion on the survey findings, and Section 5 draws the conclusions.

#### **2. Materials and Methods**

In carrying out our study, we have used the PRISMA methodology that defines the guidelines for conducting systematic reviews, which is widely accepted by most Web of Science (WoS) journals for organizing review-type articles [33]. More specifically, we have selected the "PRISMA 2020 flow diagram for new systematic reviews which included searches of databases and registers only" variant that features four main phases: articles identification, screening, eligibility, and inclusion. The goal of our systematic study is to create an overview of the domain of blockchain and IoT applications for ambient assisted living and to construct a snapshot of the state-of-the-art works for general or specific topics in this domain. This approach will also allow identifying current hot trends, future research directions, and research gaps.

The first step in our research study was to clearly define search strategy in terms of research questions, keywords, or key phrases to cover the study targeted topic of blockchain, IoT, and AAL applications. The following research questions have been selected for our study:


This led to the definition of the following main search keywords to be used in the next stage of the study:


Using the above, the second step of applying the PRISMA methodology was to select the scientific databases for the search process. In this context, we have selected Web of Science as the main database for our study since it is the most comprehensive scientific database widely recognized for including high-quality conference and journal articles from the most important publishers (MDPI, IEEE, Elsevier, ACM, Springer, Wiley, etc.). Using the WoS database allowed us to focus our search on a single platform while receiving results from articles from multiple publishers. To conduct the search, we have used the Clarivate WoS web platform [34]. As a search method in this platform, we have selected the Topic type because it covers the key information from the WoS indexed research articles: title, abstract, author, keywords, and Keywords Plus. The search keywords have been transformed into search strings in the platform, e.g., "blockchain" AND "ambient intelligence".

Figure 3 illustrates the PRISMA 2020 flow diagram used to identify the articles that were included in the review. In the PRISMA identification phase, after aggregating the search results, we have identified 491 articles matching our search criteria. We have refined this set of articles and removed duplicate records (19 items), resulting in 472 records to be included in the Screening phase. In this phase, we have defined specific inclusion criteria for our study to further filter the results, thus, removing 312 records. Similarly, to further narrow the set of records in the Eligibility phase, we defined several exclusion criteria that helped us drop another 73 records. Both criteria are presented in Table 1.

Finally, in the inclusion phase, we obtained 48 records to be considered in the study for an in-depth analysis of the presented work, concepts, approaches, and solutions for blockchain in AAL.

**Figure 3.** PRISMA 2020 flow diagram for the current study.

**Table 1.** Criteria for including and excluding articles in the study.


Figure 4 presents the included papers distribution per publishing year. It can be noticed that most of the research around the studied topics has been accelerated from 2020 onwards.

**Figure 4.** Results distribution by year.

Figure 5 shows the distribution of the selected articles using the journal/conference publisher as criteria. As it can be seen in the figure, all major highly rated publishers (Elsevier, IEEE, MDPI, and Springer) have shown interest in the blockchain and AAL research direction, 80% of the selected papers being published under one of the four.

**Figure 5.** Results distribution by publisher.

As per the types of papers included in the study, in Figure 6, we illustrate the main categories of the analyzed papers, with an emphasis on article types.

Figure 7 shows the distribution of the included papers per journal and conference proceeding highlighting that more research related to the study domain has been published in IEEE Access and Sensors MDPI journals.

**Figure 7.** Journal and conference proceedings comparison.

Table 2 summarizes the query results as the number of records together with the number of items included in the study per each category.


**Table 2.** Results overview.

#### **3. Results**

After identifying and selecting the relevant papers using the defined criteria, we have conducted a qualitative analysis to identify blockchain applications and use cases in ambient assisted living systems and the associated challenges and limitations. Most of the literature on blockchain application in healthcare focuses on the health aspects, such as the management of electronic health records, and only a few relevant papers were found on addressing aspects of patient care at home using ambient assisted living systems. Nevertheless, most of the identified papers are very recent, mostly beyond 2020, showing that blockchain technology usage in ambient assisted living is a fast-emerging field of research that will gain a lot of attention in the near future.

We have organized the reviewed papers on the basis of the most important aspects of ambient assisted living reported in the literature to which blockchain may bring significant improvements: (1) monitoring, timely follow-up, and intervention of patients or older adults living at home using IoT devices; (2) decentralized data storage to avoid single point of failure, data manipulation issues, and mistrust; and (3) privacy and security aspects of cross-continuum of care.

#### *3.1. Patient Monitoring and Intervention*

Integrating IoT with blockchain technology is used to develop decentralized ambient monitoring and intervention infrastructures using IoT devices (see Table 3). The data provided by the IoT devices can be stored on the blockchain as transactions and replicated in all the nodes of the network. The blockchain can offer an efficient environment for disseminating IoT-acquired patient data in a secure way to all relevant healthcare stakeholders [63]. Blockchain can reinforce trust and address problems related to limited access to healthcare [67].

**Table 3.** Blockchain usage benefits of IoT monitoring in AAL systems.


The integration of IoT with blockchain may contribute to the relief of pressure on sanitary systems while simultaneously providing tailored care services to enhance people's quality of life [65,94]. The growing geriatric population with chronic medical conditions increased the adoption of IoT devices for remote at-home monitoring [68] and telemedicine [69]. These have become even more evident during the COVID-19 pandemic [63,67]. An IoT taxonomy relevant for ambient assisted living systems is provided in [16,47]. Five categories have been identified: sensor-based, resource-based, communication-based, software-based, and security-based methods. Blockchain has promising features for developing data-flow architectures that integrate the monitoring devices and assure patient data-efficient dissemination to relevant healthcare stakeholders [57,64]. The marriage of blockchain with Internet of Things technology supports the paradigm shift towards preventive and personalized care systems [17,70]. Although blockchain and IoT adoption in ambient assisted living systems is still in its early stages, it can address flaws in the care processes [18] and close some communication gaps, assuring better interoperability [71,84]. An investigation into the development of smart ambulances is presented in [19]. The blockchain can be used to increase interoperability and efficiency of information exchanges with the hospital for timely intervention in an emergency department [72].

Blockchain is a good choice for establishing a decentralized, self-contained IoT system deployed in older adults' homes [75]. In [28], the authors propose an IoT based on blockchain integration architecture, a rich–thin client IoT technique for addressing the challenges associated with the restricted IoT capacities when adopting blockchain in remote monitoring and healthcare processes. In this context, the smart contracts can assure a seamless and automatic solution platform connecting a range of IoT devices relevant for remote follow-up [66]. Smart contracts are a crucial feature of blockchain technology that enables it to be used in a variety of ambient assisted living systems [14,85]. However, the smart contract concept, its operation, and how it can be used in ambient assisted living are still poorly understood [48].

Nevertheless, the main barrier to integrating IoT monitoring devices with blockchain in the context of ambient assisted living systems is scalability [62]. The researchers of [24] provide an overview of blockchain technology and explore prominent consensus methods utilized in the healthcare processes. However, as the authors pointed out in [36], there are issues to be solved, including scalability and standardization. Research has been conducted to improve the scalability of IoT to blockchain integration [73]. This is a relevant aspect of ambient monitoring and assistive services [37]. In [44], the authors propose a blockchain framework that is described as more accurate, precise, and efficient than other popular methods of storing and accessing patient records among personnel, medical stakeholders, and facilities. In [18], the authors discuss the evolution of healthcare, identifying the research gaps such as the relocation of care from hospital to home and ambient assisted care [5] that we consider to be a relevant use case for joining Wireless Body Area Networks with blockchain [74]. Improved scalability of a permissioned blockchain framework has been described in [51] using Hyperledger Fabric as an infrastructure for the blockchain network. The authors of [31] investigated a composite scalability concept which can be seen differently depending on the grade of innovation we want to achieve. The notion of blockchain scalability is discussed, including techniques and ideas for increasing core blockchain functionality and blockchain-based applications in domains such as remote care [76,81]. Blockchain and fog computing is being used in care IoT to provide safe and trustworthy transactions [95]. An Extended Signature-Based Encryption technique is proposed for healthcare IoT device authentication, as well as authorization [52]. The authors claim the suggested architecture and algorithm may offer safe transaction and transmission. Finally, [54] looks at blockchain to IoT systems and how to make them more scalable. On-chain and off-chain methodologies are contrasted, and suggestions are made to help designers create scalable blockchain-based IoT medical systems.

#### *3.2. Decentralized Data Management*

As healthcare processes become more digitalized, issues concerning safe storage, ownership, and sharing of patient personal health records and related medical data have arisen [10], and they can be addressed by using blockchain technology (Table 4). To address some of the issues mentioned above, patient data can be stored in the cloud [59], and security policies can be applied via smart contracts [86]. Increasing the amount of time that vulnerable persons can spend at home alone and how data acquisition systems can efficiently share data using blockchain are presented in [87]. Removing some of the barriers to adopting electronic patient records in management platforms through a blockchain is presented in [88]. The data collected from IoT devices can be stored in an Interplanetary File System (IPFS) storage while data access and interactions are managed through smart contracts executed on a blockchain [96]. In [12], the authors identify four possible research directions for blockchain technology in the healthcare domain: scalability, privacy and security, digital currency management, and cross-chain technology.

**Ambient Assisted Living Use Case Blockchain Usage References** Decentralized patient data management Safe, decentralized storage of data [42,59,77,82,91] Data sharing and smart contracts [25,38,39,87,88] Data ownership [12,14,25,26,49,83] Health and care processes integration [89,90] Data analytics [40,42,43,46]

**Table 4.** Blockchain usage benefits data management in AAL systems.

A blockchain-based architecture is presented in [38] to enable a distributed patient data sharing and smart-contract-based web service automation while not compromising the security and privacy of the system. To tackle the limitations of cloud-based systems, such as single point of failure, the use of decentralized data storage systems is proposed [42]. An essential insight into the possibilities of blockchain technology, particularly in the health sector, is provided in [25]. The authors discuss the reasons for using smart contract technology in healthcare and the prospects of using smart contracts in health records and sharing processes, medical testing, pharmaceutical manufacturers, big data, machine learning, security, and privacy, among other areas. The significant barriers to the use of blockchain technologies, along with scalability and storage conditions, are interoperability with legacy systems [49].

In [39], a data-sharing strategy based on the IPFS was developed, which not only increases the availability of data but also decreases data redundancy among the many stakeholders of the care ecosystem. In [14], the use of blockchain technology is discussed regarding the use of IoT in the remote monitoring of patients. Blockchain is seen as a good technology for facilitating the implementation of the internet of medical things, which refers to the interconnectedness of devices and sensors in the healthcare domain that collects real-time data [89]. The challenge with this data is that it is typically stored in a centralized location, which creates a single point of failure and raises privacy and security concerns [90], and a consortium blockchain network with smart contracts and interplanetary file systems can provide secure storage and transmission of data [77]. Important research directions in joining blockchain and ambient assisted living services are scalability, response time, blockchains interoperability, privacy, and ownership of data [83].

Big data, artificial intelligence, and distributed ledger technology, among other technologies, are blurring the barriers between the physical and digital worlds. Blockchain is a new technology and needs the development of more efficient and scalable strategies for incorporating it into the existing healthcare processes [43]. An innovative blockchain-based business model for health and care systems is described in [40]. It places the patient at the heart of the paradigm and may be used in any business situation with a set of user incentive criteria. As indicated in [42], blockchain technology may be utilized to enhance

IoT-driven care systems and tackle different difficulties. It offers a two-stage architectural solution for integrating IoT with blockchain using dew and cloudlet computing. In [46], a blockchain framework is proposed that allows data owners to create preferred access controls for electronic patient records. A two-chain architecture is used to store access controls as well as data transactions and employs a clustering strategy to handle the real growth difficulties associated with distributed ledgers.

Even though, as listed above, blockchain technology brings potential benefits for data management applications to ambient assisted living systems, there are challenges that limit its adoption [30,37]. Services built on fuzzy systems and blockchain technology are proposed in [49] to provide a behavior-driven intuitive security measure for healthcare IoT environments and networks based on blockchain. In [85], the authors explore different methods for assisting in medication usage. Blockchain can be used to store and disseminate information concerning adverse responses to prescription pharmaceuticals [97]. In [26], various scenarios are presented in the form of an analysis that verifies the key aspects of establishing, verifying, and changing people's identities. It presents various blockchain identity verification solutions available on the market built on top of public or private blockchains. Finally, a significant amount of time might be saved if patient characteristics are disseminated among all relevant stakeholders across the care continuum [91], illustrating how distributed ledgers and blockchain technology might be used for AAL systems to support decentralized data management [82].

#### *3.3. Security and Privacy*

Blockchain technology usage in ambient assisted living systems brings benefits (see Table 5) for addressing flaws and vulnerabilities, such as security flaws in smart IoT devices [41], trust and security, as well as the interoperability of such systems with legacy applications [20]. It may also circumvent the restrictions of client/server architectures in cloud-based ambient assisted living applications because of its scattered peer-to-peer nature [13].


**Table 5.** Blockchain usage benefits for the security and privacy of AAL systems.

A thorough literature review of GDPR-compliant blockchains was conducted in [32]. The essential GDPR for blockchains can be broken down into six categories that include data removal and modification, security by design, data controller and data processor obligations, consent management [35], data processing norms and lawfulness, and geographical reach. In [79], new research paths are proposed, such as the adoption of private blockchains to support the implementation of ambient assisted living systems. The authors of [41] examined recent breakthroughs in IoT-based healthcare procedures identifying critical challenges for systems development such as security, privacy, and authentication. In [43], blockchain technology was utilized to address such challenges to build a more efficient and dependable care system. Additionally, blockchain provides relevant features for ambient assisted living systems, such as data tampering and service failures [78]. Utilizing a distributed ledger, data might be visible to all users and, therefore, would allow for data integrity and provenance tracking verification [92].

In [35], a thorough assessment of the implementation of blockchain technology in the sphere of consent is presented, as well as privacy and data management. The consent of the patient is an important topic in the field of ambient assisted living systems [50]. In [60], a study was conducted on better techniques to manage informed consent so that data access is not abused and personal data protection regulations are respected. A good platform for obtaining informed consent from both a patient and a proxy (in the case of patients who have no discernment or cannot make decisions for themselves) is the Hyperledger fabric network blockchain [27] with smart contracts. Blockchain platforms may combine several roles and stakeholders in the care system, such as institutions that regulate access to personal data, data consumers, research institutions such as universities, and devices and technologies that acquire data [98]. A consent management framework that incorporates Distributed Ledger Technologies is presented in [21]. The platform offers an onion-layered secure way of transmitting sensitive data and a better way of accessing management methods. IPFS can be used for sharing files in a safe, transparent, and decentralized way in ambient assisted living systems [14]. Similar solutions based on another type of blockchains can be found in the literature [99], but they are not focused directly on consent, even if they can be interpreted as access to data itself [100].

Lately, differential privacy has emerged as perhaps the most successful privacy guarding solution for IoT medical and care infrastructure [13]. Some experimental findings and confidentiality proofs that demonstrate a particular suggested protocol that has a reasonable computational cost, as well as security safeguards for digital healthcare transactions, are presented in [45]. For decentralized and trustworthy healthcare data interactions, smart contracts and Elliptic Curve Encryption can be employed. One goal of ambient assisted living data protection protocol is to be resistant to a variety of threats and to have reasonable operating and computing capabilities [15]. A blockchain solution using a zero-knowledge-based authentication architecture to tackle privacy issues is presented in [29]. The architecture authenticates devices without revealing any information about the identity of the user. The paper also introduces the ZKNimble cipher, which is suitable to be used by devices that do not benefit from a good processing power.

According to [27], the ambient assisted living and care systems should deliver and share patient data through a secure transfer to ensure the confidentiality of data [93]. This was made feasible using a blockchain-based approach to the system's architectural design [55], while work still needs to be carried out on interoperability. It is explained in [20] how many IoT applications in healthcare are no different from those in any other area, and the research should concentrate on the industry's unique requirements, such as good levels of privacy and security. In this context, the number of blockchain-based applications in healthcare has increased lately, but the domain highly demands interdisciplinary studies [30]. A blockchain classification for IoT applications is provided in [47]. The authors explore the most prevalent blockchain systems for healthcare.

In [50], a blockchain-based solution is proposed for managing private data using Hyperledger Fabric and Caliper and can be used in various domains such as healthcare. The core benefits of blockchain technology for such systems are immutability, traceability, and transparency [80]. In [22], a decentralized and scalable architecture is presented supporting device access, authentication, as well as data security. A novel authentication protocol has been devised and constructed on Physical Unclonable Functions cryptographic primitives. This makes it practically difficult to predict the key values of the protocol because of the randomness provided by the physical architecture of the protocol. The system suggested in [53] enables medical officials to authenticate data received by a common wearable device with a verification error of less than 1% and a price compared with fewer as being much cheaper for one hour of observing the activity. A decentralized specific ring-based authorization method, as well as an authentication scheme and patient's records anonymity algorithms, are provided to increase the proposed system's security [58]. It allows for decentralized automated identity management, privacy, and security [61]. Finally, in [15], the authors use blockchain to protect patients' anonymity and privacy from several potential threats while enabling important institutions to interact with one another. Only authorized users have access to the genuine identities, addresses, as well as medical data of patients

in the proposed system [101]. Authorities should use blockchain to tackle the issue of cyber-attacks tampering with sensor data [56].

#### **4. Discussion**

As the population of the world is aging, societal challenges will need to be faced, especially about the delivery of care, which needs to be improved, and new care system paths need to be designed. At the same time, the development of IoT sensors and technology such as blockchain can ease this process by the implementation of ambient assisted living services which aim at moving the care from hospitals and care centers to home. The integration of sensors in older adults or patients' homes to enable remote follow-up and care is seen as key in delaying.

The ambient assisted living systems address many of the concerns of patients in this transition towards remote care and personalized interventions, such as (1) time-consuming process for healthcare professionals caused by the lack of accurate monitoring and followup support, (2) patient data-sharing gaps across the care continuum, (3) not having a proper care support network in place to reduce patient anxiety or worries; (4) patients and family caregivers lacking sufficient knowledge and skills to optimize self-care; (5) patient difficulties in adherence to postdischarge instructions, e.g., medication usage or behavioral changes.

Despite advantages brought to the care process, the ambient assisted living solutions have a rather limited adoption mostly because of the problems related to IoT sensors integration, data sharing, trust, ethical considerations, data confidentiality, privacy, etc. (see Table 6). As shown by the qualitative review conducted, blockchain technology can play a significant role in addressing some of the concerns related to the ambient assisted living services adoption, but at the same time, several technological barriers require further investigation.


**Table 6.** Assisted living issues and blockchain solutions.

Blockchain scalability is important for integrating the technology into ambient assisted living systems. The monitoring data related to the patient's state and well-being, captured using IoT sensors, must be disseminated through the blockchain network. However, nowadays, the scalability of blockchain networks is low for handling an increasing number of transactions as more people will utilize the platform. The quantity of data to be saved on the blockchain will increase in tandem with the number of transactions on the network. It may cause problems related to the network speed and high costs. It is difficult to assess blockchain performance concerning the integration of IoT monitoring devices in living environments and the storage and dissemination of patient data for remote follow-up. Because the technology is decentralized, there is no benchmark against which to compare performance. However, there are a few methods for assessing performance. One method is to look at how many transactions a blockchain network processes in a particular amount of time. Another technique to assess performance is to look at a blockchain network's average transaction time.

As scalability is a significant issue of the blockchain, managing a high number of transactions is important to gain broad acceptance in ambient assisted living systems. However, there are several solutions for improving scalability. Sharding is one potential solution in which the blockchain is split into several shards, each of which may execute transactions concurrently and can be correlated with the organization and data-sharing procedures in healthcare. It would enable the network to handle a considerably higher volume of transactions without compromising speed or efficiency. Another option is offchain scaling, which entails shifting part of the data off-chain, and this can be a relevant option even to relieve some of the privacy concerns as the patient monitoring data will be stored at the edge.

In the blockchain, there is a lot of room for privacy. This is relevant for ambient assisted living systems where private data and informed consent must be carefully handled. With blockchain, we may construct a safe and private transactional environment to share patient health records and data. Blockchain, if properly used, has the potential to eliminate fraud and improve transparency. However, ensuring privacy needs further research and development. One of the difficulties is that all parties must have a common concept of the data confidentiality, and new care and data-sharing paths need to be created in the healthcare systems. The creation of a digital identity is another way that blockchain may aid in the enforcement of privacy. This would allow us to choose which personal information is shared and with whom. In an ambient assisted living system, we may, for example, select to share the data partially with our family and not at all with our insurance company. A digital identity would offer us complete control over our personal information, allowing us to guarantee that it is shared only with the people we choose.

Another issue of ambient assisted living systems is the possibility of data leaks and modification. Unauthorized parties may have access to monitoring data if they is not protected adequately. Therefore, data may be encrypted using blockchain. This makes it extremely difficult for anyone who is not allowed to read it and modify it. A decentralized network is what defines a blockchain. It implies that our data are not stored in a single area, making it extremely difficult to be modified. Smart contracts can be created using blockchain technology. Integrated into ambient assisted living systems, they may automatize the IoT devices integration as well as the data processing jobs. As a result, we may designate how and by whom our data can be utilized. If someone tries to use our data in a way we have not approved, the smart contract will prohibit them immediately. The data stay private and safe by utilizing blockchain to encrypt data, build a decentralized network, and construct smart contracts.

Finally, the ability of various systems to communicate and interoperate is important for care and support systems that need to integrate stakeholders across the whole continuum of care. The capacity to exchange currency and data between various blockchain networks is one of the advantages of blockchain interoperability. It may contribute to developing a more integrated and efficient care ecosystem. Another advantage of blockchain interoperability is that it might reduce fragmentation risks. It can assist in guaranteeing that there is a single source of truth and that information is not segregated by allowing multiple blockchain networks to collaborate. Interoperability on the blockchain can let consumers have a more efficient experience. Users may hopefully avoid dealing with numerous distinct care applications by allowing blockchains to interact and integrate. Interoperability across blockchains can also assist in enforcing security. It is possible to uncover potential risks and weaknesses by allowing multiple blockchain networks to share data and information. Interoperability on the blockchain can also assist in cutting expenses. It is possible to prevent duplication of effort and resources.

#### **5. Conclusions**

In this paper, we have used the PRISMA methodology to identify, study, and report the relevant state-of-the-art literature around blockchain and its applicability in ambient active living. We have defined inclusion and exclusion criteria, have set several international databases for pooling articles, and finally selected 87 research papers in the qualitative study. As many of the desirable features of ambient assisted living systems may be assured by integrating and using the blockchain technology, we have organized the review to reflect the solutions in relation to the IoT monitoring and integration of environmental sensors, managing and sharing of data, and security and privacy aspects.

The outcome of the study shows that the integration of blockchain with ambient assisted living systems is a hot topic in many of the papers published after 2020. The adoption of remote assistive care was accelerated by the COVID-19 pandemic, and as shown by the qualitative review conducted, blockchain technology can play a significant role in addressing some of the concerns related to ambient assisted living services adoption. Although blockchain technology has the potential to revolutionize the care and ambient assisted living industry, more research is needed to fully understand its implications and applications. Future research includes expanding and replicating existing frameworks, performance, scalability, privacy, and interoperability of blockchain systems in IoT healthcare applications. More studies are needed on the adoption of blockchain in the health and care ecosystem, concentrating on topics such as scalability, costs, creation of new care and data-sharing paths for care transition from hospital to home, governance, and interoperability.

**Author Contributions:** Conceptualization, A.-I.F. and I.A.; funding acquisition, T.C. and I.A.; investigation, A.-I.F. and I.A.; methodology, A.-I.F. and I.A.; writing—original draft, A.-I.F. and T.C.; writing—review & editing, I.A. and T.C. All authors have read and agreed to the published version of the manuscript.

**Funding:** This work has been supported by three grants from the Romanian Ministry of Research, Innovation and Digitization, CNCS/CCCDI—UEFISCDI, with co-funding from the AAL Programme (AAL159/2020 H2HCare, AAL264/2021 engAGE, and AAL162/2020 ReMember-Me) and one grant of Romanian Ministry of Research, Innovation and Digitization, CNCS/CCCDI—UEFISCDI (PN-III-P3-3.6-H2020-2020-0031).

**Institutional Review Board Statement:** Not applicable.

**Informed Consent Statement:** Not applicable.

**Data Availability Statement:** Not applicable.

**Conflicts of Interest:** The authors declare no conflict of interest.

#### **References**


MDPI St. Alban-Anlage 66 4052 Basel Switzerland Tel. +41 61 683 77 34 Fax +41 61 302 89 18 www.mdpi.com

*Future Internet* Editorial Office E-mail: futureinternet@mdpi.com www.mdpi.com/journal/futureinternet

MDPI St. Alban-Anlage 66 4052 Basel Switzerland Tel: +41 61 683 77 34

www.mdpi.com ISBN 978-3-0365-6252-0