BUAV: A Blockchain Based Secure UA V-Assisted Data Acquisition Scheme in Internet of Things

I. INTRODUCTION

INTERNET of things (IoT) has generated considerable attention not only in industrial fields but also in academic research. IoT is a network of objects, equipped with sensors, actuators, software, etc., that are connected via Internet. Moreover, these objects can collect information from their surroundings and can interchange these data among each other [1]. Based on the promising possibilities attributed to IoT, an estimation of appending 30 billion devices in the network by 2020 has been made [2]. However, IoT is not only confined to sensing and information interchange. Currently, IoT can make spontaneous decisions based on the sensed data. IoT has improved the quality of our lives by contributing to the development of several different sectors including healthcare [3]–[8], agriculture [9]–[12], smart homes [13]–[15], smart grids [16]–[20], and others [21].

Unmanned aerial vehicles (UAVs) is an example of an emerging technology that achieved widespread popularity owing to its potential for diverse applications. Initially, UAVs were confined to applications within the military. However, the use of these devices has subsequently been extended to civil applications [22]. The advantages of UAVs is their ease of deployment, low maintenance and acquisition cost, and the ability to access almost any areas [23]. Moreover, some UAVs contain sensors, actuators, high computational power, etc., which not only can accumulate data along with spatial information but also can process it, reach decisions and act according to the decision [24]–[26]. UAVs can be posted to locations that are difficult to access in order to provide assistance to IoTs. Occasionally, UAVs can operate as a server while providing services to IoTs. In addition, UAVs can spread network connection to IoTs for the non-lineof- sight zones. Moreover, UAVs can save the energy of devices by assisting in forwarding the data and can quickly be replaced in the occurrence of a fault, while providing assistance to IoTs. UAVs can also cover a large area which can help to optimize the deployment cost.

Mobile edge computing (MEC) is another promising initiative that draws cloud computing facilities closer to user proximity at the edge of the mobile network and provides services by utilizing radio access networks (RANs) [27]. The purpose of MEC is to provide ultra-low latency, high bandwidth, and real-time services to mobile subscribers [28]. However, collecting data from IoTs via the cloud creates latency issues, along with challenges related to low throughput and single-node failure [29]. MEC is a potential candidate for alleviating the aforementioned issues by providing real-time data acquisition services from IoT devices via the utilization of UAVs. However, the data acquisition process is prone to threats like the man-inthe- middle, spoofing etc. Moreover, the collected data may experience unauthorised modifications in the storage, which may lead to uncertainty regarding the integrity of the data. Therefore, a secure scheme for data acquisition via UAV is required.

Among the existing studies, in [30], a UAV based fog computing platform that aids IoT devices has been proposed. In addition, an architecture in which information is obtained from IoT using UAV (sometimes UAV to UAV) and stored in the cloud has been appended. In [31], UAV served as a fog node so that it could provide real-time assistance to IoT devices. However, this may consume a significant amount of energy and may reduce the flight time of UAV. In [31], an approach was proposed in which UAVs are deployed based on client positions so that the client can perform queries and acquire data from IoTs with less delay. In [31], UAV served as a gateway for data acquisition and UAVs were controlled using UAVs control server. In that proposed scheme, data are stored in the global server that serves the client by obtaining data from UAVs. In [32], a UAV-assisted data collection scheme for a wireless sensor network (WSN) was presented. To perform data acquisition, they first divided that region into multiple areas. Subsequently, they deployed UAVs based on the plan established while dividing the region. In [33], a smart farming scheme was presented in which UAV was utilized to communicate with ground sensors and aid these sensors. In [33], a testbed considering IEEE 802.15.4-based communication between UAV and ground sensors was implemented. A prototype was presented in wherein a UAV served as a base station (BS) and performed wireless power transfer and communications with sensors simultaneously, in [34]. In [35], a RESTful approach was presented in which UAV equipped with IoT relays data to cloud services along with a vertical handover mechanism in which UAV can shift between different modes of communication such as Wi-Fi and satellite for beyond-line-of-sight communication issues, to increase reliability. However, the aforementioned schemes did not consider any security issues while deploying UAVs. In addition, they did not add information regarding data management after collecting from IoTs, which may create an issue concerning the integrity of stored data.

Blockchain is a distributed ledger technology that is shared among peers in a network where the peers hold the same copies of the ledger [36]. Blockchain was first introduced by Satoshi Nakamoto in a white paper, called "Bitcoin: A peer-to-peer electronic cash system", in 2008 [37]. Initially, blockchain was confined to the documentation of financial transactions. However, owing to its promising functionality (e.g., immutability, smart contract, etc.), this technology is currently in use in the recording of medical data, tracking of products in the supply chain, etc. [38]. In blockchain, data are deposited in a block and each block has a unique hash, which is generated based on the content of the block [39]. Each block points to the previous block’s hash; thus, blocks stay in the chain, and that is why it is called blockchain. Blockchain adopts asymmetric encryption to maintain security [40]. Each user holds a private key and a public key that is generated from the private key. Every user uses this public key as an identity in the network, and thus, the identity of the user remains obscured [41]. However, blockchain also utilizes a Merkle tree [39]. A Merkle tree is a structure that is generated from the hash of the data. Any alteration in the data causes a change in the Merkle tree. By utilizing the Merkle tree, blockchain preserves the integrity of data. However, to add a block to the chain, every node, called a miner or validator, must agree on the validity of the block [42]. These characteristics can be possible solutions against the aforementioned issues (i.e., cyber threats and data integrity) in data acquisition from IoT using a UAV.

A blockchain based data acquisition scheme is proposed in which data are gathered from IoTs via UAV and kept securely in blockchain at MEC, to alleviate the aforementioned issues. The major contributions of this paper are summarized as follows.

A scheme is proposed to perform data acquisition from IoT devices.

A discussion on security based on different vulnerabilities is provided.

The impact of [TeX:] $$\eta \text { -hash }$$ bloom filter¹ is simulated both in MATLAB for edge server and Python for UAV.

¹Bloom filter is a data structure to check the existence of an item in a set consuming less memory [43].

We have implemented the proposed scheme and the performance is examined by throughput, processing time, energy consumption, and latency.

We have implemented blockchain using ethereum and the performance is investigated in terms of write, read, latency, and delay.

The rest of the sections are arranged as follows: Section II represents the data acquisition scheme. In Section III, the process of data acquisition is depicted. Section IV illustrates a security analysis of the proposed scheme. The simulation and experimental setup are discussed in Section V. Finally, Section VI summarizes the mains conclusions and examines future research directions.

II. PROPOSED SCHEME

We devise a blockchain based data acquisition scheme (termed as “BUAV”) that facilitates the collection of data from IoTs using a UAV, as presented in Fig. 1.

A. Basic Idea

BUAV concentrates on data acquisition from IoT devices using UAVs as well as the deposition of the collected data in a secure way to avoid compromising data integrity and BUAV also ensures secure data transmission. It was assumed that all valid IoT devices and UAVs are registered in the scheme. In BUAV, IoT devices intend to transmit data to the MEC. Before transferring data, IoT device performs encryption. This data is then transmitted to UAVs along with their identity. Upon receiving the data, UAVs perform decryption and check the validity of the identity of the sender. For validating devices, [TeX:] $$\eta$$-hash bloom filter is adopted in BUAV. However, if the identity is not valid, then UAVs discard the data and append that invalid identity to a vulnerable list. If the invalid identity continues to transmit data, then UAVs block the communication channel for that identity for a specific period. In BUAV, UAV decrypts and validates the data in order to prevent malicious devices at an early stage. If a malicious device continuously sends invalid data and UAV just forwards it to the server without any validation then MECS gets a lot of traffic containing invalid data. But, MECS cannot block the sender because data are coming through the UAV (if MECS wants to block the sender then it has to block UAV) and only UAV can identify the sender. That is why UAV decrypts the data and prevents malicious devices from reaching the server. However, for a valid identity, UAVs forward the data to the MEC server. When MEC server receives the data, MEC server verifies the validity of the sender. In case of a valid identity, MEC stores the data in blockchain. When data is added to the network, block sealing process is initiated. Upon receiving the acknowledgement from other validators, data is added to the network including a private cloud.

B. Entities

BUAV consists of four entities: IoT device (IoTD), UAV, MEC server (MECS), and private cloud (PC). The entities of BUAV are depicted below:

IoTD: IoT device collects data and transmits it to the MECS. This device consists of sensors and actuators and it can both sense the environment and perform tasks according to the instruction.

UAV: UAV receives data from IoTD and relays these data to the server. UAV also authorizes requests prior to forwarding to the server. Every UAV maintains a list of IoTDs and other UAVs, which it utilizes to perform the authentication process using [TeX:] $$\eta$$-hash bloom filters before forwarding data to MECS.

MECS: MEC server collects data from IoTD via UAV that are subsequently stored in blockchain. MEC not only maintains basic information (i.e., device name, mac address, device type, etc.) but also spatial information (i.e., latitude, longitude, etc.) that assists MEC server in maintaining the data acquisition process. MEC server also validates UAV and IoTD before including data into blockchain.

PC: The private cloud is composed of private servers; the PC is linked with MECS via backhaul networks. Since the PC is also serving as a client of blockchain, it also gets the update when new data is added to MECS.

C. Notations

A list of common notations including their description is compiled in Table1.

III. COMMUNICATIONS IN THE PROPOSED SCHEME

A. Registration

We assumed that valid IoTDs and UAVs are registered users. Prior to registration in the system, UAV or IoTD generates a

unique hash based on the mac address of the device [TeX:] $$\delta_{m a c},$$ timestamp [TeX:] $$\tau_{c},$$ and random salt hash [TeX:] $$\hat{S}_{\hbar}.$$ Let h be the hash,

where h is used to generate private key [TeX:] $$\wp_{\kappa}$$ and subsequently, a public key [TeX:] $$\varrho_{\kappa}$$ is created from [TeX:] $$\wp_{\kappa}.$$ Let ^E is a point on the elliptic curve containing (x, y).

After generating keys, IoTD transmits [TeX:] $$\varrho_{\kappa}$$ to MECS along with device information (i.e., [TeX:] $$\delta_{m a c},$$ latitude, longitude, etc.). [TeX:] $$\hat{\varrho}_{\kappa}$$ is used as an identity of a IoTD. MECS then stores these information in a smart contract [TeX:] $$\mathrm{C}_{\delta}$$ of blockchain.

B. Data Generation

BUAV utilizes [TeX:] $$\eta \text { -hash }$$ bloom filters [TeX:] $$(\eta=1,2, \cdots)$$ to validate IoTDs before forwarding data to MECS. MECS fetches the device list from [TeX:] $$\mathrm{C}_{\delta} . \text { Let } \bar{\partial}$$ be the list,

Here, [TeX:] $$\mathfrak{k}$$ is the location containing [TeX:] $$\langle l a t, l o n\rangle$$ and [TeX:] $$\mathfrak{r}$$ is radius of the location of . Prior to validating IoTD, UAV requires filter table [TeX:] $$\overline{\mathfrak{F}} | \mathfrak{F} \in\{0,1\}.$$ When a UAV registers or connect with MECS, MECS generates [TeX:] $$\overline{\mathfrak{F}}$$ and shares it with UAV. Let [TeX:] $$\overline{\mathfrak{F}}$$ is the generated table,

where n is the total number of devices. [TeX:] $$\eta$$ is the number of hashes that are employed in the process. Bloom filter has a false positive issue that can be reduced by controlling the number of hash functions and data size [43]. However, there is a limit to the use of hash functions in the bloom filter. Let n is number of [TeX:] $$\mathfrak{d},$$ and p is the acceptance of false positive rate [44],

where [TeX:] $$\eta$$ is the maximum number of hash function that is suitable for [TeX:] $$\beta F.$$

C. Data Transmission

In BUAV, a IoTD starts transmitting a data to MECS [TeX:] $$\Upsilon$$ via UAV . Prior to transmitting , creates a signature [TeX:] $$\varepsilon$$ from by employing the private key [TeX:] $$\wp_{\kappa}^{\sigma} \text { of } \sigma,$$

After generating [TeX:] $$\varepsilon, \sigma \text { encrypts } \alpha$$ along with [TeX:] $$\varepsilon \text { and } \hat{\varrho}_{\kappa}^{\sigma}$$ by using the public key [TeX:] $$\hat{\varrho}_{\kappa}^{\mathcal{U}} \text { of } \Psi . \text { Let } \beta$$ is the encrypted data,

Subsequently, transmits to . Let [TeX:] $$\tau_{p}$$ is the total processing time for preparing data at ,

v

Here, [TeX:] $$\tau_{\varepsilon}^{\sigma} \text { and } \tau_{\beta}^{\sigma}$$ is the processing time for [TeX:] $$\varepsilon \text { and } \beta,$$ respectively. Let [TeX:] $$T^{\{\sigma \rightarrow \mho\}}$$ be the time for the transmission of from[TeX:] $$\sigma \text { to } \mho,$$

where [TeX:] $$\tau_{d}^{\{\sigma \rightarrow \mho\}}$$ is the transmission delay from [TeX:] $$\sigma \text { to } \mho.$$ Upon receiving [TeX:] $$\beta, \mho \text { decrypts } \beta$$ by employing the private key [TeX:] $$\wp_{\kappa}^{\mho}$$ of , as shown in Algorithm 1. Let [TeX:] $$\breve{d}$$ is the decrypted data,

After obtaining [TeX:] $$\breve{d},\mho$$ first checks [TeX:] $$B_{L}$$ and subsequently, it checks the validity of [TeX:] $$\hat{\varrho}_{\kappa}^{\sigma}$$ by utilizing [TeX:] $$\beta F$$. Let [TeX:] $$\ddot{f}$$ is the validity result,

If [TeX:] $$\ddot{f}$$ is 0 then [TeX:] $$\hat{\varrho}_{\kappa}^{\sigma}$$ is not valid. discards [TeX:] $$\breve{d}$$ instantly and places [TeX:] $$\hat{\varrho}_{\kappa}^{\sigma} \text { under } V_{L} . \text { If } \hat{\varrho}_{\kappa}^{\sigma}$$ continues to transmit invalid requests then after a threshold number of requests [TeX:] $$\Re_{n}^{\mho}, \mho \text { adds } \hat{\varrho}_{\kappa}^{\sigma} \text { to } B_{L}.$$ However, for the valid [TeX:] $$\hat{\varrho}_{\kappa}^{\sigma}, \mho$$ encrypts the data along with [TeX:] $$\hat{\varrho}_{\kappa}^{\mho}, \alpha, \hat{\varrho}_{\kappa}^{\sigma},$$ and [TeX:] $$\varepsilon$$ by using the public key of [TeX:] $$\Upsilon . \text { Let } \gamma$$ is the encrypted data,

Subsequently, forwards[TeX:] $$\gamma \text { to } \Upsilon.$$ Let [TeX:] $$\tau_{p}$$ is the total processing time for preparing data at ,

where [TeX:] $$\tau_{\breve{d}}^{\mho}, \tau_{\ddot{f}}^{\mho}, \text { and } \tau_{\gamma}^{\mho}$$ is the processing time for [TeX:] $$\breve{d},\ddot{f}$$ and [TeX:] $$\gamma,$$ respectively. Let [TeX:] $$T^{\{\mho \rightarrow \Upsilon\}}$$ is the time to transmit [TeX:] $$\gamma \text { from } \mho \text { to } \Upsilon,$$

where [TeX:] $$\tau_{d}^{\{\mho \rightarrow \Upsilon\}}$$ is the transmission delay from [TeX:] $$\mho \text { to } \Upsilon$$

When [TeX:] $$\Upsilon \text { receives } \gamma, \Upsilon \text { decrypts } \gamma$$ by employing the private key [TeX:] $$\wp_{\kappa}^{\curlyvee} \text { of } \Upsilon,$$ as shown in Algorithm 2. Let [TeX:] $$\tilde{d}$$ is the decrypted data,

After getting [TeX:] $$\tilde{d}, \Upsilon$$ first checks the [TeX:] $$B_{L}$$ and subsequently, [TeX:] $$\Upsilon$$ checks the validity of [TeX:] $$\hat{\varrho}_{\kappa}^{\mho} \text { and } \hat{\varrho}_{\kappa}^{\sigma} \text { by using } \beta F$$. Let [TeX:] $$\check{f}$$ is the validity result,

If [TeX:] $$\check{f}$$ is 0 then either [TeX:] $$\hat{\varrho}_{\kappa}^{\mho} \text { or } \hat{\varrho}_{\kappa_{1}}^{\sigma}$$ is not valid. [TeX:] $$\Upsilon \text { discards } \tilde{d}$$ instantly and put [TeX:] $$\hat{\varrho}_{\kappa}^{\mho} \text { in } \bar{V}_{L} \text { . If } \hat{\varrho}_{\kappa}^{\mho}$$ continues to transmit invalid

requests then after a threshold number of requests [TeX:] $$\ddot{\Re}_{n}^{\curlyvee}, \Upsilon$$ puts [TeX:] $$\hat{\mho_{\kappa}^{J} \text { in } B_{L}$$ and the channel is blocked for a threshold amount of time [TeX:] $$\ddot{\Re}_{\tau}^{\curlyvee}.$$ However, for the valid [TeX:] $$\hat{\mho}_{\kappa}^{J}, \Upsilon$$ continues to process [TeX:] $\tilde{d}.$$ Before adding to storage, [TeX:] $$\Upsilon$$ checks the integrity of checks the integrity of by verifying the signature of [TeX:] $$\sigma . \text { Let } \ddot{v}$$ is verification result,

If [TeX:] $$\ddot{v} \text { is true, then } \Upsilon$$ transmits [TeX:] $$\alpha$$ for validating and adding in the blockchain. Let [TeX:] $$\tau_{p}$$ is the total processing time for validating data at [TeX:] $$\Upsilon$$

where [TeX:] $$\tau_{\tilde{d}}^{\mho}, \tau_{\check{f}}^{\mho}, \text { and } \tau_{\ddot{v}}^{\mho}$$ are the processing time for [TeX:] $$\tilde{d}, \check{f}, \text { and } \ddot{v},$$ respectively. Let [TeX:] $$T^{\{\sigma \rightarrow \mho \rightarrow \Upsilon\}}$$ is the total time to transmit and process successfully from [TeX:] $$\sigma \text { to } \Upsilon \text { via } \mho$$ including the validation process. By adding (8) and (13), it can be written that,

When [TeX:] $$\alpha \text { is valid, } \Upsilon$$ starts to add [TeX:] $$\alpha$$ to the blockchain [TeX:] $$\mathbb{B}.$$ We considered a private blockchain network in which the identity of validators [TeX:] $$\ddot{\nu}$$ (those that create blocks) is known to everyone. In BUAV, each block holds a [TeX:] $$\mathcal{T}^{\prime}$$ number of transactions, as illustrated in Fig. 2. In Fig. 2, the first block is the genesis block that contains the list of validators, chainId (i.e., network id), etc. After that, each blockchain contains the data of IoT devices. However, a validator proposes a block [TeX:] $$$$ and other validators validate the block. This process is performed in a round-robin algorithm. Let [TeX:] $$\hat{f}$$ contains the validation result,

where [TeX:] $$\ddot{m}$$ is the total number of validators. Once, every validator validates the block, the block is appended in the chain.

D. UAV Requisition

If disconnects with and cannot reconnect with , transmits request [TeX:] $$\ddot{r} \text { to } \Upsilon$$ to send information regarding new [TeX:] $$$$ in order to facilitate the transfer of data. There exists a direct communication link between IoTD and MECS. However, IoTD utilizes that channel only when IoTD cannot locate any UAV nearby. Moreover, transmitting data through that channel drains more energy than the communication channel that exists between IoT and UAV. Therefore, continuous transmission can decrease the lifetime of the battery of IoTD. In order to increase the lifetime,

BUAV utilizes UAV for relaying data. Prior to sending [TeX:] $$\ddot{r}, \sigma$$ creates a signature [TeX:] $$\ddot{\varepsilon} \text { from } \ddot{r}$$ by employing the private key [TeX:] $$\wp_{\kappa}^{\sigma} \ \mathrm{of} \ \sigma,$$

Subsequently, [TeX:] $$\sigma \text { encrypts } \ddot{r} \text { along with } \hat{\varrho}_{\kappa}^{\sigma} \text { and } \ddot{\varepsilon}$$ by employing [TeX:] $$\hat{\varrho}_{\kappa}^{\Upsilon} . \text { Let } \hat{\beta}$$ is the encrypted data,

Upon receiving [TeX:] $$\hat{\beta}, \gamma$$ performs a decryption by using [TeX:] $$\wp_{\kappa}^{\curlyvee},$$ as shown in Algorithm 3. Let [TeX:] $$\acute{d}$$ is the decrypted data,

After obtaining [TeX:] $$\acute{d}, \Upsilon$$ checks the validity of [TeX:] $$\hat{\varrho}_{\kappa}^{\sigma}$$ by utilizing [TeX:] $$\beta F . \text { Let } \grave{f}$$ is the validity result,

If [TeX:] $$\grave{f}$$ returns a value of 1, then [TeX:] $$\Upsilon$$ continues to process the request. Prior to searching [TeX:] $$\mho \ \text { for } \sigma, \Upsilon$$ verifies the signature which is transmitted within the request. Let [TeX:] $$\check{v}$$ is verification result,

If [TeX:] $$\check{v}$$ contains true then [TeX:] $$\Upsilon$$ retrieves the spatial information of . Subsequently, [TeX:] $$\Upsilon$$ retrieves all UAVs from the list of devices [TeX:] $$\ddot{\sigma} . \text { Let } \overline{\mho}$$ is the collection of UAVs,

After retrieving [TeX:] $$\overline{\mho}, \Upsilon$$ calculates the geo distance between [TeX:] $$\sigma\text { and } \overline{\mho}.$$ Subsequently, [TeX:] $$\Upsilon$$ sorts the list in the ascending order based on the geo distance and picks the top threshold number [TeX:] $$\Re_{g d}^{\mho} \text { of } \mho.$$ Before transmitting the results, [TeX:] $$\Upsilon$$ first creates a signature [TeX:] $$\varepsilon_{\Upsilon} \text { by employing } \wp_{\kappa}^{\Upsilon},$$

Here, [TeX:] $$\overline{\mho}_{gd}$$ is the list of selected , where [TeX:] $$\overline{\mho}_{gd}=\bigcup_{i=1}^{\Re_{g d}^{\mho}}(\overline{\mho_{i}})$$ After generating [TeX:] $$\varepsilon_{\Upsilon}, \Upsilon \text { encrypts } \overline{mho}_{gd}$$ by employing [TeX:] $$\hat{\varrho}_{\kappa}^{\sigma} . \text { Let } \hat{\gamma}$$ is the encrypted data,

After completing [TeX:] $$\hat{\gamma}, \Upsilon \text { returns } \hat{\gamma} \text { to } \sigma.$$ Upon receiving [TeX:] $$\hat{\gamma}, \sigma$$ first performs a decryption by using [TeX:] $$\wp_{\kappa}^{\sigma}$$,

Subsequently, [TeX:] $$\sigma$$ verifies the integrity from [TeX:] $$\varepsilon_{\Upsilon} . \text { Let } \dot{v}$$ is the result of verification,

If [TeX:] $$\dot{v}$$ returns a value of true then reads the list, connects with a suitable , and continues to transmit data. Let [TeX:] $$T^{\{\sigma \rightarrow \Upsilon \rightarrow \sigma\}}$$ is the total time for requisitioning a UAV and get response from [TeX:] $$\Upsilon,$$

IV. SECURITY ANALYSIS

A. Protection Against Eavesdroppers

In BUAV, data is transferred from [TeX:] $$\sigma \text { to } \Upsilon \text { via } \mho$$ and in addition, sends the request for [TeX:] $$\mho \text { to } \Upsilon.$$ The area between and , and [TeX:] $$\Upsilon, \text { and } \sigma$$ are vulnerable to an eavesdropper [TeX:] $$\vartheta.$$ However, BUAV provides protection against eavesdroppers. In BUAV, every [TeX:] $$\sigma, \Upsilon, \text { and } \mho \text { have their own } \wp_{\kappa}$$ and a corresponding [TeX:] $$\hat{\varrho}_{\kappa} . \text { When } \sigma \text { transmits } \alpha \text { to } \mho, \sigma$$ encrypts the information by utilizing (6). Upon receiving , it is decrypted by using (9) and the identity is verified using (10). After verification, reencrypts information using (11) and forwards [TeX:] $$\gamma \text { to } \Upsilon.$$ While requesting the location of a new [TeX:] $$\mho, \sigma$$ first encrypts the request using (21) and sends the request to [TeX:] $$\Upsilon.$$ Upon receiving [TeX:] $$\hat{\beta},$$ it is decrypted by [TeX:] $$\Upsilon$$ by using (22) and the identity is verified by employing (23). After processing the request, [TeX:] $$\Upsilon$$ encrypts the response using (27) and returns to . In order to read data between [TeX:] $$\sigma \text { and } \mho, \vartheta \text { requires knowledge of } \wp_{\kappa}^{\mho},$$ which is only known to . Without [TeX:] $$\wp_{\kappa}^{\mho}, \vartheta$$ cannot decrypt the data. If [TeX:] $$\vartheta \text { intends to read } \gamma$$ then [TeX:] $$\wp_{\kappa}^{\Upsilon}$$ is needed which is only known to [TeX:] $$\Upsilon.$$ In order to read [TeX:] $$\text { and } \hat{\gamma}, \vartheta$$ needs to know [TeX:] $$\hat{\varrho}_{\kappa}^{\Upsilon} \text { and } \hat{\varrho}_{\kappa}^{\sigma},$$ respectively, which are not publicly available. As such, [TeX:] $$\vartheta$$ cannot exercise eavesdropping in BUAV.

B. Key-Spoof Resistance

An attacker [TeX:] $$\ddot{\vartheta}$$ cannot directly perform eavesdropping because [TeX:] $$\wp_{\kappa}$$ is unknown to [TeX:] $$\ddot{\vartheta}.$$ To determine [TeX:] $$\wp_{\kappa},\ddot{\vartheta}$$ must guess [TeX:] $$\wp_{\kappa.$$ According to (1), [TeX:] $$\wp_{\kappa.$$ is generated using [TeX:] $$\delta_{m a c}, \tau_{c} \text { and } \hat{S}_{\hbar} \cdot \tau_{c} \text { and } \hat{S}_{\hbar}$$ are totally random. Suppose, [TeX:] $$\wp_{\kappa}$$ is 32 bytes or 256 bits long. To predict the correct [TeX:] $$\wp_{\kappa},\ddot{\vartheta}$$ has to go through the sequence of 256. For 256 bits, there are [TeX:] $$2^{256}$$ possible sequences and among them, only one can be the right [TeX:] $$\wp_{\kappa}.$$ The probability of predicting [TeX:] $$\wp_{\kappa}$$ is [TeX:] $$1 / 2^{256}=2^{-256}$$ and that is not practically feasible. Let, [TeX:] $$\delta_{m a c}$$ be [TeX:] $$\hat{i} \text { bits, } \tau_{c} \text { represents } \hat{j} \text { bits, and } \hat{S}_{\hbar} \text { represents } \hat{k}.$$ If [TeX:] $$\ddot{\vartheta}$$ wants to guess the properties of [TeX:] $$\wp_{\kappa},$$ then the probability of guessing correclty is [TeX:] $$1 / 2^{\hat{i}} \times 1 / 2^{\hat{j}} \times 1 / 2^{\hat{k}}=2^{-\hat{i}} \times 2^{-\hat{j}} \times 2^{-\hat{k}},$$ which is also not practically feasible.

which is also not practically feasible.

In BUAV, [TeX:] $$\sigma \text { transfers } \alpha \text { to } \Upsilon, \text { via } \mho . \text { When } \Upsilon \text { receives } \gamma$$ from [TeX:] $$\mho, \Upsilon$$ first decrypts [TeX:] $$\gamma$$ by employing (14) and subsequently, verifies the identity using (15). However, [TeX:] $$\Upsilon$$ requires verification that data originates from the original sender, [TeX:] $$\sigma . \ \mho \text { decrypts } \beta$$ by employing (9) and retrieves . In this case, there is a vulnerability in that the data may experience alteration. Before transmitting [TeX:] $$\alpha, \sigma$$ creates a signature of using (5). When [TeX:] $$\Upsilon \text { receives } \alpha, \Upsilon$$ verifies by employing (16). If [TeX:] $$\ddot{v} \text { is } f a l s e, \text { then } \alpha$$ is altered and [TeX:] $$\Upsilon \text { discards } \alpha . \Upsilon$$ only appends data to blockchain when [TeX:] $$\ddot{{v}}$$ is true. During the requisition of [TeX:] $$\mho, \sigma$$ creates a signature by utilizing (20), so that, [TeX:] $$\Upsilon$$ can verify the authenticity of using (24). Based on this approach, BUAV prevents altered data from being appended to Blockchain. After storing data in traditional databases, there is the possibility that the data may be altered. Considering this issue, BUAV stores the data in Blockchain. When data arrives at [TeX:] $$\Upsilon, \text { after verification, } \Upsilon$$ transmits the data to the blockchain network. Once the data is received in the network, validators create blocks after utilizing (19). Given that data is stored in the chain, every validator holds the same copy of the data. In blockchain, every block has a unique hash which is the identity of that block. The next block keeps the hash of the previous block and they are chained together. However, this hash is generated from the data, timestamp, nonce, etc. To main

tain integrity, blockchain uses a Merkle tree. This is a structure in which the leaf nodes holds the hash of the data. When an alteration is performed to the data, the hash of the tree is also changed. Subsequently, the hash of the block is also changed and thus, the chain of blocks break. To restore the chain, consent from the majority of the validator is required, which makes these changes technically unfeasible.

V. PERFORMANCE EVALUATION

This section represents the performance evaluation of BUAV. The performance is analyzed by simulation and experiment and the results are discussed is two subsections.

A. Simulation Results

A simulation was performed using MATLAB for estimating the effects in MEC server and another simulation was performed for estimating the effects in UAV. In UAV, Python was utilized for simulating results. The simulation parameters are provided in Table 2. For simulation purposes, an Intel(R) Core(TM) i5-4670 CPU @ 3.40 GHz was used as MEC server with 32 GB RAM. For UAV, Broadcom BCM2837B0, Cortex- A53 (ARMv8) 64-bit SoC @ 1.4 GHz was used with 1 GB RAM.

Fig. 3 demonstrates the results of the simulation that were performed in the MEC server. The time for processing the data of [TeX:] $$\eta \text { -hash }$$ bloom filter that contains information on the different number of devices is shown in Fig. 3(a). Milliseconds was considered as the unit of the processing time. In Fig. 3(a), processing time increases with the increase in the number of devices. In addition, the value of [TeX:] $$\eta$$ affects the processing time. Increasing the number of [TeX:] $$\eta$$ results in an increase in the processing time. As a result, [TeX:] $$\eta=3$$ requires more time than [TeX:] $$\eta=2, \text { and } \eta=2$$ [TeX:] $$\eta=2, \text { and } \eta=2$$ requires more time-consuming than [TeX:] $$\eta=1.$$

Fig. 3(b) illustrates the expected transmission of data containing information for the different devices that are generated from [TeX:] $$\eta \text { -hash }$$ bloom filter. An increase in the number of devices also results in an increase in the data size. However, [TeX:] $$\eta=1,2, \text { and } 3$$ produces the same amount of data because data in the list contains either 0 or 1 and the size of 0 and 1 is same. Therefore, differences in [TeX:] $$\eta$$ have no impact on the data size generated from [TeX:] $$\eta \text { -hash }$$ bloom filter.

Fig. 3(c) depicts the transmission of data generated from bloom filter and other data structure apart from bloom filter containing the information of the different number of devices. A hash table was considered as a non-bloom filter data structure.

Given that, there is no influence of [TeX:] $$\eta$$ on data size, [TeX:] $$\eta=1$$ was used for this simulation. The amount of data in both the bloom filter and the hash table increases with an increase in the number of devices. However, the data size of the hash table increases dramatically in comparison with the bloom filter. In particular, the hash table is initially twice of the data size of the bloom filter. For more devices, this difference approaches thrice the data size of the bloom filter. Therefore, by using a bloom filter, BUAV compresses space in a UAV.

Fig. 4 demonstrates the simulation results that were obtained for the UAV. The time for validating the identity of the different devices utilizing [TeX:] $$\eta \text { -hash }$$ bloom filter is shown in Fig. 4(a). Milliseconds was considered as the unit for the validation time. With the increase in the number of devices that require validation, the validation time also increases. The change in the value of [TeX:] $$\eta$$ leads to a change in the validation time. Increasing the number of [TeX:] $$\eta$$ requires more time for the validation process. This is the reason why [TeX:] $$\eta=3$$ requires more time than [TeX:] $$\eta=2 \text { and } \eta=2$$ requires more time than [TeX:] $$\eta=1.$$

Fig. 4(b) illustrates the energy consumption during the validation process. Joule was considered as the unit of energy consumption. With the increase in the number of devices for the validation process, energy consumption also increases. Given that, the increase in [TeX:] $$\eta$$ requires more time for the validation process, [TeX:] $$\eta=3$$ consumes more energy than [TeX:] $$\eta=2 \text { and } \eta=2$$ consumes more energy than [TeX:] $$\eta=1.$$

Fig. 4(c) represents the time required to validate the devices in the presence of malicious devices. This simulation was performed for 10,000 devices. The increase in the percentage of malicious devices, even in the 100 percentage malicious devices scenario, does not affect the validation time. This is because, for both valid and malicious devices, [TeX:] $$\eta \text { -hash }$$ bloom filter checks either 0 or 1. However, the validation time increases with an increase in [TeX:] $$\eta;$$ but, it remains the same for different percentages of malicious devices.

Fig. 5 demonstrates the rate of false positive for the different percentage of malicious devices. As bloom filter surrounds with the false positive issue, it is necessary to check the false positive rate. 10,000 devices were considered for this simulation. In this simulation, the false positive rate is 0 for [TeX:] $$\eta=1,2, \text { and } 3,$$ even

in the 100 percentage malicious devices scenario.

B. Experimental Results

The experiment was performed indoor, as shown in Fig. 6. The parameters used in the experiment are described in Table 3. An Intel(R) Core(TM) i5-4670 CPU @ 3.40 GHz was used as MEC server with 32 GB RAM. Node.js was used to create the server. 4 raspberry pi 3 model b+ were utilized and sensors (i.e., flame, temperature, humidity, light) were attached in these devices. These devices were considered as IoTD with the primary task of sensing the environment and transmitting the result to the MEC server via UAV. The middleware in IoTD was built using Python. The communication between UAV and IoTD was performed over Bluetooth and the communication between UAV and MEC server was performed over Wi-Fi. Parrot Bebop 2 was used as a UAV and raspberry pi 3 model b+ was attached for maintaining communication with IoTD and MEC server, as shown in Fig. 6(a). The middleware for UAV was written using Python. IoTDs were deployed randomly and UAV was placed in the center of IoTDs, as shown in Figs. 6(b) and 6(c). The proposed scheme was built over ethereum. In ethereum, a private network was created, named BUAV-B, containing 10 validators. Geth was used as an ethereum client and web.js for RPC call. In order to set up 10 validators, 10 computers were used to create a local area network (LAN). Each pc contained geth and connected with each other. Proof of authority (PoA) was used for performing the consensus mechanism.

Fig. 7 shows the energy consumption for transferring data from a IoTD to other entities (e.g., UAV, MEC server, and cloud) directly. Intel(R) Xeon(R) Processor E5-2697A V4@2.60 GHz with 32 GB RAM was considered for the cloud server and the cloud server is hosted in US server at 69,162,66,34. CentOS 7.5 was used as the OS in the cloud server. In order to connect to the cloud, the IoT device is connected with the ipTIME A2004NS-R router and the EFM ipTIME A2004NS-R is connected to the internet. To connect to the MEC server, an ipTime N100 mini was used to open an access point from the MEC server. To connect to the UAV, Bluetooth 4.2 was used. Fig. 7 shows that it requires

more energy to communicate with the cloud, and with the increase in data size, energy consumption also increases. On the contrary, communication with the MEC server consumes less energy although the energy consumption increases with an increase in the size of the data. Communication with UAV consumes less energy than the MEC server which is almost half of the MEC server because communicating using Bluetooth consumes less energy than Wi-Fi. With an increase in data size, the energy consumption increases very slowly in contrast with the MEC and cloud server. From the results, direct communication with the cloud server, IoTs spent more energy than with the MEC server and direct communication with the MEC, IoTs spent more energy than with UAV.

Fig. 8 demonstrates the result of the experiments performed in the network. In Fig. 8(a), the throughput of the network over different time is presented. The communication channel of BUAV is compared before and after the application of security. Over time, in both channel’s throughput increases. However, the throughput of the channel without security is higher than the channel with security. This is because, after applying security, data has to be validated before being forwarded to the next hop.

Fig. 8(b) illustrates the total amount of data received in MEC server. For this experiment, 1 and 3 were considered as valid IoTDs and 2 and 4 were considered as malicious IoTDs. This simulation was performed for 10 s. Data from IoT-1 and IoT-3 successfully reached MEC server because both of them are valid. As a result, both successfully passed the validation process in UAV and 10,370 and 10,889 bytes received at MEC server, respectively. However, data from IoT-2 and IoT-4 were discarded in UAV because they could not pass the validation because they are not in the device list. Therefore, IoT-2 and IoT-4 cannot reach MEC server.

Fig. 8(c) shows the time to process security actions in IoT device, UAV, and MEC server for different data sizes. Equation (7) was utilized for IoT device, (12) was utilized for UAV, and (17) was utilized for the MEC server in order to calculate the processing time. The processing time increased with the increase of the data size for IoT device, UAV, and MEC server. However, MEC server’s computation power is much higher than that of UAV and IoT. That is why the processing time for MEC server is negligible in contrast with IoT device and UAV. However, UAV performs a decryption process which is slower than encryption. As such, the processing time is higher in UAV than IoT device.

Fig. 8(d) represents the energy consumption during the processing of security actions in IoT device, UAV, and MEC server for different data sizes. Energy consumption in the CPU was considered while processing the security actions of the MEC server. Given that, the CPU has significant computational power, the processing time is much less in comparison with that of UAV and IoT device. However, MEC server requires a large amount of energy in order to maintain continuity. With the increase in the data size, the energy consumption of the IoT device, UAV and MEC server also increases. Given that, UAV has a decryption mechanism in security actions, it consumes more power than IoT device.

Fig. 8(e) depicts the processing time for performing individual security mechanism for different data sizes. Given that, MEC has significant computational power, the difference in the processing time between MEC and IoT/UAV is very high. It is notable that the processing time for every action increases with an increase in the data size. However, decryption requires more time than encryption and signing the data is more time consuming than verifying the data. In RSA, the private key is larger than the public key and due to its size, more time is needed for processing. Both decryption and signing use a private key in order to decrypt and sign, respectively. As such, decryption and signing require more time in contrast to encryption and verifying. However, this phenomenon is also visible in the MEC server. Despite its high computation capability, decryption and signing take more time than encryption and verifying.

Fig. 8(f) represents the latency for searching UAV that varies

for the different number of UAVs. Equation (30) was utilized in order to calculate latency. However, with the increase in the number of UAVs, latency also increases. For more UAVs, it is required more time to calculate distance and more time to sort the data set which increases the latency. Overall, that increase in latency is very small.

Fig. 9 illustrates the result of the experiments performed in blockchain in MEC server. Fig. 9(a) shows the amount of data that was added in blockchain over time. 2, 5, 8, and 10 validator scenarios were considered during these experiments. With the increase in time, the amount of data addition also increased. However, these increases vary depending on the number of validators. The speed of adding data is almost the same for 2 and 5, and the speed of data addition is almost the same for 5 and 10. However, with the increase of the validator, the rate of addition of data in the blockchain decreases. In PoA, from the onset, everyone has the list of validators and blocks are appended in a round robin manner. Prior to the addition of the block in the chain, it is necessary to get an agreement by validators which increases the delay in the network and as a result of this delay, the amount of data also decreases.

Fig. 9(b) represents the changes of the data added in blockchain over time when considering the different percentage of validators that are not available for the validation process. 10 validators were considered while performing this experiment. The experiment was performed for the full active node (everyone is active), 10% down (10% of the total validators), 20% down (20% of the total validators), 30% down (30% of the total validators), and 40% down (40% of the total validators). However, in PoA, one validator proposes a block and the other validators sign it if the proposal is valid. This process proceeds one at a time in a round robin way. However, if a validator is not available for the validation process, he misses the chance to propose a block, his chance moves to the next validator, and this process goes on. But, this creates a delay in the network which causes a decrease in the amount of data added to the network in contrast with the full active node. With the increase in the percentage of unavailability of validators, the rate of addition of data in the network decreases.

Fig. 9(c) outlines the number of queries that can be performed at different times. In blockchain, everyone has the same version of the data and during data reading from blockchain, data were retrieved from the local copy of the requester. This is why the validators do not play a role during the reading of data from blockchain. However, how many queries can be performed at different times were considered. With the increase in time, the queries also increase.

Fig. 9(d) describes the latency associated with the addition of data in blockchain for the different validators. From 2 to 10 validators appearance were considered. In Fig. 9(d), latency increases with the increasing number of validators. It is notable that, to sign a block, a delay is created from the validators. Thus, an increase in the number of validators increases latency.

Fig. 9(e) presents the delay in transferring data from IoTD to MEC server. In this experiments, data were transmitted in two ways: (1) Transmit 1 [TeX:] $$(\mathrm{IoTD} \rightarrow \mathrm{UAV} \rightarrow \mathrm{MECS}),$$ and (2) Transmit 2 [TeX:] $$(\mathrm{IoTD} \rightarrow \mathrm{UAV} \rightarrow \mathrm{UAV} \rightarrow \mathrm{MECS}).$$ Transmission by including blockchain [TeX:] $$\text { (IoTD } \rightarrow \text { UAV } \rightarrow \text { MECS } \rightarrow \text { Blockchain and }\text { IoTD } \rightarrow \text { UAV } \rightarrow \text { UAV } \rightarrow \text { MECS } \rightarrow \text { Blockchain) }$$ and excluding blockchain were considered. For the case without blockchain, the delay in Transmit 2 is higher than Transmit 1. This is because, in Transmit 2, the data has to pass through one more hop than in the case of Transmit 1. In addition, this data also experiences more security mechanisms than Transmit 1, which increases the delay in Transmit 2 in compare to Transmit 1. In comparison with the exclusion of blockchain, the incorporation of blockchain increases the delay in both Transmit 1 and Transmit 2. This is because the inclusion of blockchain introduces additional latency during the addition of the block in blockchain along with the security validation delay in MEC server.

VI. CONCLUSIONS AND FUTURE WORK

In this paper, a secure data collection scheme was introduced in which data are collected from IoT devices (IoTDs) with the assistance of unmanned aerial vehicle (UAV). After collection, the data are stored securely in blockchain at mobile edge computing (MEC) server. While transferring data from IoTDs, encryption is performed using UAV’s public key and a signature is created using IoTD’s private key. UAV receives that data and after the decryption, the identity of IoTD is validated using [TeX:] $$\eta \text { -hash }$$ bloom filter. Subsequently, data are forwarded to MECS and after validating, it is stored by MEC in blockchain that is signed by the validators. Simulations were performed using MATLAB in order to examine the impact of [TeX:] $$\eta \text { -hash }$$ bloom filter for both in MEC server and UAV. Implementation of BUAV was done and experiments were performed in that implementation in to order to test the feasibility. Some future directions are listed below:

BUAV supports single UAV in the data acquisition which can be extended with multi-UAV to increase the quality of service. But, providing security for multi-UAV is very challenging which can be a future research topic.

The dynamic distribution of IoT devices and mobility of UAV during secure data acquisition needs to be investigated which can be subjected to future works.

BUAV does not consider the incentivization of the validator which is kept for future research.