Secure Blockchain-Enabled Authentication Key Management Framework with Big Data Analytics for Drones in Networks Beyond 5G Applications

: One of the most signiﬁcant recent advances in technology is the advent of unmanned aerial vehicles (UAVs), i.e., drones. They have widened the scope of possible applications and provided a platform for a wide range of creative responses to a variety of challenges. The Internet of Drones (IoD) is a relatively new concept that has arisen as a consequence of the combination of drones and the Internet. The ﬁfth-generation (5G) and beyond cellular networks (i.e., drones in networks beyond 5G) are promising solutions for achieving safe drone operations and applications. They may have many applications, like surveillance or urban areas, security, surveillance, retaliation, delivering items, smart farming, ﬁlm production, capturing nature videos, and many more. Due to the fact that it is susceptible to a wide variety of cyber-attacks, there are certain concerns regarding the privacy and security of IoD communications. In this paper, a secure blockchain-enabled authentication key management framework with the big data analytics feature for drones in networks beyond 5G applications is proposed (in short, SBBDA-IoD). The security of SBBDA-IoD against multiple attacks is demonstrated through a detailed security analysis. The Scyther tool is used to perform a formal security veriﬁcation test on the SBBDA-IoD’s security, conﬁrming the system’s resistance to various potential attacks. A detailed comparative analysis has identiﬁed that SBBDA-IoD outperforms the other schemes by a signiﬁcant margin. Finally, a real-world implementation of SBBDA-IoD is shown to evaluate its effect on several measures of performance.


Introduction
The term Internet of Drones (IoD) refers to the infrastructure that has been set up to enable users, servers, and drones to communicate with one another and share resources via the Internet.In point of fact, drones are rapidly becoming more mainstream goods, allowing users to pilot many drones simultaneously for various purposes within confined spaces [1].Drones, also known as unmanned aerial vehicles (UAVs), are valuable instruments that can be used to address the issues that occur in people's day-to-day lives.An Internet of Drones (IoD) that connects drones is a trend that is widely desired to improve the safety and quality of flight in light of the growing number of drones that are operating in lowaltitude airspace.This is because connecting drones will create an IoD [2,3].Some of the important components of a drone are the RC transmitter, multirotor frame, motors/speed controller, propellers, flight controller, battery, and landing gear.Integration of unmanned aerial vehicles (UAVs, also known as drones) into "fifth-generation (5G) and beyond cellular networks" is a promising solution for achieving safe UAV operation in addition to permitting expanded uses with the mission-specific payload delivery of information.This is because of the developments in cellular technologies and the widespread deployment of cellular facilities [4,5].They may have many applications, i.e., surveillance of a city, security, and surveillance of border areas, delivery of items (i.e., medicines, vaccines), smart farming, film productions, capturing nature's activities (i.e., a volcano city, waterfall), etc., [1,6].The navigation and control of the airspace around them are essential for all these applications.

Research Motivation
Entities in an IoD-based network, such as drones, servers, and users, communicate through an open channel, i.e., the Internet.As a result, there may be certain concerns regarding the confidentiality and safety of the information that is communicated over IoD.It is possible that it could be susceptible to attacks such as message replaying, impersonation, man-in-the-middle (MiTM), the physically compromising a drone, malware propagation, credential leakage, disclosure of sensitive data, and other similar attacks [7,8].Thus, we require some security frameworks to protect the IoD networks from the various attacks that could be launched against them [9,10].Data are stored within the blocks of a blockchain, which is a sort of distributed ledger technology.Blockchains are used in cryptocurrency transactions.These can safely process and store the data, and these guard the data against any attack that could involve data disclosure or data change [11,12].The information kept in the blockchain can be accessed and used for various purposes, including the prediction of certain occurrences (for example, the traffic situation in a city or the weather forecast).Various approaches to data analysis based on machine learning can be utilized for undertakings of this nature [8].Hence, a similar approach has been followed in the proposed scheme.
The following section will detail the research contributions made by this paper.

Research Contributions
The following is a list of the research contributions that this work makes: • A secure blockchain-enabled authentication key management framework with big data analytics for drones in networks beyond 5G applications is proposed.In short, we call it SBBDA-IoD.

•
The resilience of SBBDA-IoD against multiple attacks is demonstrated through a security analysis.

•
The Scyther tool is used to perform a formal test of SBBDA-IoD's security, confirming the system's resistance to a variety of cyber-attacks.

•
The comparative analysis found that SBBDA-IoD outperformed the other schemes by a significant margin.• A real-world implementation of SBBDA-IoD is shown to evaluate its effect on several measures of performance.

Related Work
In this section, we discuss some of the existing authentication and key agreement methods and provide specifics regarding these methods.
Ali et al. [13] introduced an improved method known as a temporal credentialbased anonymous lightweight authentication scheme (iTCALAS).This made use of the lightweight symmetric key primitives in conjunction with temporal credentials.The suggested method, while retaining its lightweight nature, provides security against a wide variety of previously recognized risks, such as traceability and stolen verifiers, while at the same time maintaining its inherent simplicity.The extended scalability of the iTCALAS that has been presented also allows it to function in an IoD environment with many flying zones or clusters.The authentication mechanisms that are going to be used for the secure commu-nication of unmanned aerial vehicles (UAVs) were discussed by Rodrigues et al. [14].They investigated and compared two authentication algorithms designed for wireless sensor networks (WSNs) and adapted for use with UAVs.The tests were carried out by examining the amount of time spent executing security-related activities such as hash tables and elliptic curve operations.Ever [15] has shown a safe authentication framework for mobile sinks, which could be utilized in applications for the Internet of Drones.The UAVs that had the potential to operate as mobile sinks were taken into consideration.The work that had already been performed on the authentication of the WSN-UAV environment was expanded.It was stated that there was a secure authentication framework that makes use of elliptic-curve cryptosystems.The aforementioned structure was put through a series of tests to establish whether or not it was resistant to substantial and well-known conceivable attacks.These attacks included those that targeted data secrecy, mutual authentication, password guessing, and key impersonation, among other things.Bera et al. [16] came up with an idea for a technique of access control that may be used in the Internet of Drones (IoD) setting for the purpose of identifying and mitigating the effects of unauthorized UAVs.They have used blockchain technology in their scheme.The transactional data were recorded on a private blockchain that was legitimate and authentic in every way.These data included the standard secure data that were transferred from a drone to the ground station server and the anomalous (suspected) data utilized to detect unauthorized UAVs that were stored over the private blockchain.These data were collected and transmitted by the ground station server.
Yazdinejad et al. [11] proposed a secure authentication model intended to use blockchain technology.The approach was intended to be used by drones in smart cities.The strategy ensured the fewest possible delays in the process.In a network of drones, they created a zone-based architecture and used a tailored decentralized consensus mechanism for drones in a smart city called "drone-based delegated proof of stake (DDPOS)".Both of these technologies are referred to as drone-based delegated proof of stake.When utilizing this strategy, drones did not need to go through the re-authentication process when moving between zones.Singh et al. [12] also addressed the development of the Internet of Drones as well as the industrial applications of this emerging technology.The development of this technology has brought about major worries, one of which has always been related to the unmanned robots' level of security.As a result, they brought attention to the most important security concerns and then suggested using cutting-edge blockchain technology as the most important answer to these concerns.Feng et al. [17] suggested a solution for blockchain-based cross-domain authentication that was designed for the intelligent Internet of Drones with 5G.This approach was developed with the intention of overcoming the limitations that were discussed earlier.Their technique relied on a large number of signatures, each of which was established by means of threshold sharing; this allowed them to successfully build an identity federation for collaborative domains.Because of this, they were able to facilitate joining and leaving domains.Utilizing smart contracts as a means of authentication allowed for reliable communication between devices that operated in many domains.A blockchain-based drone delivery system (GaRuDa system) was proposed by Gupta et al. [7].This system might be utilized for applications that are linked to Healthcare 5.0.Their plan combined the Internet of Things and blockchain technology by way of an Internet that was enabled with 5G capabilities to facilitate the low-latency and responsive distribution of medical supplies that could be chronologically monitored and tracked among many stakeholders.In addition, this distribution of medical supplies could be monitored and tracked in real-time.Bera et al. [8] offered a security architecture for safe communication in IoD that was supported by smart contracts based on blockchain technology and was envisioned using artificial intelligence (AI).The security analysis indicated that the framework being presented was safe against the several different sorts of attacks that may be carried out against it.
Lwin et al. [18] explored the creation of a city geographic dashboard, which had the ability to collect, exchange, and visualize geographic data that were gathered from satellites, Internet of Things devices (i.e., drones), and other types of big data.Abualigah et al. [19] provided a complete examination of the Internet of Things and its applications, deployments, and integrations.The Internet of Things applications, cloud and fog computing frameworks, unmanned aerial vehicles (UAVs), wireless sensor networks (WSNs), mobile computing, and business models were the key areas of focus for them.Gharibi et al. [1] offered a theoretical framework as an example for the construction of the IoD.They also determined the criteria that an IoD system must meet based on the architecture of the system in order for it to be regarded as successful.
Pu et al. [20] suggested a technique for user authentication and key agreement that was simple to implement and kept users' personal information private.They developed a physical unclonable function (PUF) and chaotic system in order to allow mutual authentication and establish a secure session key between the various communication participants.This was accomplished through the use of cryptography.The goal of this study, which was conducted by Yahuza et al. [6], was to conduct an analysis of recent advancements in the privacy and security issues that were related to IoD.They looked into the different types of drones to determine how much risk they posed to privacy and safety.After that, they discussed the importance of a secure architecture for IoD and proposed one.In addition to this, they provided a full taxonomy of attacks, which was possible in IoD systems.
Krichen et al. [21] examined the current state-of-the-art formal methods that have been applied to the definition and verification of smart contracts.This was performed with the intention of reducing the likelihood that caused errors and bugs.It avoided any costs that might have been caused as a result.In addition, they have identified a number of difficulties as well as potential guidelines for future research in relation to this new research tonic.Abdellatif and Brousmiche et al. [22] developed a formal modeling approach to verify the behavior of a smart contract within the environment in which it could be executed.They tested their formalism by applying it to a real-world example of a smart contract and analyzing the breaches it contained using a statical model checking approach.
Most of the schemes discussed here lack important functionality features and are vulnerable to various attacks.The blockchain-enabled mechanism can also help improve the stored data's security, which has been utilized for secure big data analytics.Hence, in this paper, we focus on the design of a secure blockchain-enabled authentication key management framework with big data analytics applicable for networks beyond 5G applications.The assessment of the closely related existing schemes is given in Table 1.

System Model
The system models, i.e., the network model (overall architecture) of the proposed SBBDA-IoD and its associated threat model, are discussed below.

Network Model
In Figure 1, we see the network representation of SBBDA-IoD.This network includes drones, ground-based servers, cloud-based servers, and control rooms.Drones collect data as they fly over designated areas (for city monitoring, smart farming, drug delivery, etc.) and transmit it to the ground station servers.The drone data are received by the ground station servers, where they are processed.The data are transmitted from the ground station servers to the connected cloud servers.The communications among the drones, ground station servers, and cloud servers happen through the open channel (i.e., the Internet), on which various attacks are possible.In order to estimate the traffic on a city street, determine the likelihood of a security attack, etc., the data are saved and analyzed on cloud servers.As discussed earlier, numerous cyber-attacks can target the numerous forms of communication that occur among the aforementioned entities.To protect against these attacks and the data being communicated, we need some sort of security mechanism (such as authentication, access control, or key management).In this paper, we present a method for both drone-to-drone and drone-to-ground station servers to successfully establish mutual authentication and session keys [16].First, there will be secure mutual authentication among the drones, ground station servers, and cloud servers; then, they establish session keys for their secure data transmission.The control room also houses the network registration authority, which is responsible for registering the various nodes that make up the network (drones, ground station servers, and cloud nodes).Cloud servers are the resource-rich entities (having high communication, computation, and storage capabilities) of the network and are the building blocks of a peer-to-peer cloud server (P2PCS) network.Cloud servers handle the most crucial operations, such as implementing blockchain and analyzing massive amounts of data [11,12].This means that cloud servers are the semi-trusted entities of the network.It is assumed that the network's registration authority has not been compromised because it is the trusted entity of the network.In the SBBDA-IoD, we can have multiple control rooms along with multiple registration authorities, which can be organized as per the network's size and requirements.

Threat Model
The Dolev-Yao (DY) threat model, which at the present time is thought of as the standard de facto, was used in the design of the SBBDA-IoD [23].According to the DY model, two separate entities can begin communicating with one another across an unsecured network (for instance, over the Internet).Unreliability exists at the endpoint entities, which include things like drones, ground station servers, and cloud servers.An adversary A, whether active or passive, may read, change, or delete the communications that are sent across a network that is not protected from outside interference.Some of the potential attacks that the proposed SBBDA-IoD takes care of include replay attacks, manin-the-middle (MiTM) attacks, impersonation attacks, privileged insider attacks, stolen verifier attacks, physical drone capture attacks, ephemeral secret leakage (ESL) attacks, secret data leakage attacks, etc.Another significant adversary model established by Canetti and Krawczyk (CK) is one we used in the SBBDA-IoD as well [24].At this point, A can use all of the DY model's capabilities.In addition, A has the ability to acquire the session states, which are the credentials and session keys associated with a particular session.A can manually grab some drones by utilizing a technique that involves complex power analysis and then access the information that is stored in the memory of those devices [25].The information gathered can also be used to start further operations and launch malicious attacks, such as establishing secret session keys and credentials, conducting the privilegedinsider attack, data replaying, conducting the drone physical capture attack, data replaying, conducting the privileged-insider attack, conducting the malware injecting and scripting attacks, conducting the DoS attack, impersonation attack, credentials leakage, and man-inthe-middle (MiTM) attacks.Attacks with malware injection can take many forms, including spyware attacks, rootkit attacks, ransomware attacks, the insertion of Trojan horses, and the launch of virus and worm attacks.The ground station servers are the entities within the network that are only partially trusted, and they are also deployed with some degree of physical security (such as a locking system or security guards) [26].As a result, there is no way that its physical integrity may be compromised via physical stealing.The cloud servers are also assumed to be the trusted network entities, and they are responsible for the data analysis.The DY model does not account for all possible forms of attack, such as the unauthorized disclosure of session states and the unauthorized computation of session keys.The CK-adversary model takes into account attacks of this nature.As a result, in the design of the SBBDA-IoD, we considered both the CK-adversary model and the DY model.

The Proposed Scheme: SBBDA-IoD
In this section, we provide the details of the proposed SBBDA-IoD.Various notations used in this paper are listed in Table 2.The SBBDA-IoD is divided into several phases, i.e., "registration phase, authentication, and key establishment phase, dynamic device addition phase, key management phase, blockchain implementation phase, and big data analytics phase".Here, it is important to mention that the secure mutual authentications and key establishment phases are executed between a drone and the other legitimate drone and between the drone and the ground station server.These phases are elaborated as follows.
Corresponding public parameter of n DR i ID GSS k and RID GSS k Identity and pseudo-identity of Essential registration parameter of GSS k ID CS l and RID CS l Identity and pseudo-identity of Public key of CS l A An adversary

Registration Phase
In this phase, the control room's registration authority CRA performs the registration of other entities, i.e., drones, ground station servers, and cloud servers.The steps are given below.

Registration of Drones
The control room's registration authority, CRA, registers a drone as per the following steps.After that, "CRA selects a non-singular elliptic curve over a finite field" as given below.Suppose there are "2 constants u ∈ Z q and v ∈ Z q , where Z q = {0, 1, . . ., q − 1} and q > 3 should be a prime".Again, RA chooses "a non-singular elliptic curve E q (u, v): y 2 = x 3 + ux + v over the finite field GF(q)".For instance, "4u 3 + 27v 2 = 0 (mod q) with a point at infinity or zero point O".Let G be a base point in E q (u, v) with a similar big order like q. CRA then generates a secret key number of DR i as n DR i and the associated public parameter as , G} in the memory of DR i .The drone DR i can then be dispatched to the designated area for use.• RGDR3: In a similar way, the registration of DR j is performed.Then, DR j contains values like, {RIN DR j , RID DR j , TOT DR j , (n DR j , N DR j ), ERP DR j , h(•), E q (u, v), G} in its memory.

Registration of Ground Station Servers
Using the following steps, the control room's registration authority CRA registers a ground station server GSS k .
• RGGS1: For the registration of GSS k , CRA first generates its identity as ID GSS k and secret key as k GSS k , it then computes the pseudo-identity of GSS k as Furthermore, CRA computes its essential registration parameter as

Registration of Cloud Servers
The control room's registration authority CRA registers a cloud server CS l using the following steps.
• RGCS1: For the registration of CS l , CRA first generates its identity as ID CS l and secret key as k CS l .After that, CRA produces the pseudo-identity of CS l as RID CS l = h(ID CS l || k CS l || RID CRA ).CRA also computes the public key of CS l as

Authentication and Key Establishment Phase
Secure mutual authentications and key establishment between drones and between drones and the ground station servers necessitate this step.Detailed explanations of each stage are given as follows.

Authentication and Key Establishment between Drone DR i and Drone DR j
The following describes the authentication and key establishment between drones DR i and DR j .
• AKADD1: Before starting the process of authentication and key establishment, the drones DR i and DR j share their pseudo-identification number with each other in a secure way.For example, for this task, DR i can send message to DR j .DR j can decrypt and read the value RI N DR i as D n DR j (MM 1 ) = RI N DR i .In a similar way, DR i can obtain the value of RI N DR j from DR j in a secure way.Furthermore, DR i produces a random secret value rv DR i and a fresh timestamp value T 1 .Then, If it matches, then DR i is authenticated with Dr j .Furthermore, DR j generates a random secret value rv DR j and a fresh timestamp value T 2 .Again, DR j computes M 3 = h(rv DR j || RID DR j ) ⊕ h(RID DR j || T 2 ).After these calculations, DR j computes its session key as where ∆T is the maximum transmission delay and T * 3 is the time at which msg 3 was received.Furthermore, DR j computes M 5 = h(SK DR j ,DR i || T 3 ) and checks M 5 = M 5 ?If it matches, then DR j assumes that the session key computed by DR i is correct.Eventually, DR i and DR j establish session key SK DR i ,DR j = (SK DR j ,DR i ) for their secure communication.

Authentication and Key Establishment between Drone DR i and Ground Station Server GSS k
The authentication and key establishment details between the drone DR i and the ground station server GSS k are given below.) and checks m SKV = m SKV ?If they match, GSS k assumes that the session key that DR i came up with is right.In this case, the session key verification works.Eventually, DR i and GSS k agree on session key SK DR i ,GSS k = (SK GSS k ,DR i ) so that they can send data securely.

Dynamic Device Addition Phase
This step must be performed before new drones can be added to the network.As a drone can sometimes malfunction or have its work stopped.We need to take the following steps for a new drone to be added to the network.

•
DDDR1: CRA generates an identity for drone DR ν i as ID ν DR i and secret key as k ν DR i .CRA then computes the pseudo-identity of , G} in the memory of DR ν i .Then, DR ν i is deployed in the assigned zone as per the requirement.CRA also shares the registration information of drones, i.e., TOT ν DR i and RID ν DR i with the existing GSS k in a secure way through shared master secret key MK CRA−GSS .

Key Management Phase between GSS k and CS l
For the secure transmission of their data, GSS k and CS l can use their secret and public key pairs, i.e., (k GSS k , Q GSS k ) and (k CS l , Q CS l ).For example, when GSS k has to send its data DT GSS k to CS l , then GSS k can perform encryption over it through Q CS l , i.e., MSG GC 1 = E CS l (DT GSS k ).Upon the arrival of MSG GC 1 , CS l can perform decryption as D k CS l (MSG GC 1 ) and read out the value of DT GSS k in a secure way.Here, it is important to mention that, to perform the above-discussed encryption/decryption, the standard ECC algorithm can be used on both GSS k and CS l sides as these are resource-rich devices.Both GSS k and CS l have good computation and communication capabilities.

Blockchain Implementation Phase
This phase is used to implement the blockchain of the drone-related data.When a drone, say DR i , sends some information to the connected GSS k , that GSS k creates a partial block PB GSS k .The partial block includes information like an owner of the block (i.e., OW GSS k ), the public key of the owner (i.e., Q GSS k ), and encrypted transactions (i.e., TR X i | i = 1, 2, • • • , num tx ).Then, GSS k sends the information of the partial block to the connected CS l through the established session key SK GSS k ,CS l .After receiving PB GSS k from GSS k , CS l creates the full block FB CS l from it.FB CS l contains information like the block's identity BID CS l , the hash of this block H ASH FB CS l , the hash of previous block H ASH FB CS l −1 , the timestamp value TS FB CS l , random nonce value RN FB CS l , OW GSS k , Q GSS k , TR X i , and the signature of this block (i.e., SG FB CS l using a standard algorithm like "Elliptic Curve Digital Signature Algorithm (ECDSA))".Then, CS l broadcasts it to its peer-to-peer cloud server network (P2PCS).Then, the miners (i.e., authorized cloud servers of the P2PCS network) execute a consensus process using some standard algorithm (i.e., practical byzantine fault tolerance (pBFT) [27,28]).After the steps of the consensus process have successfully been completed, the new block FB CS l is added to the blockchain BC DRN .Using machine learning algorithms, the data saved in the blockchain can be used to make predictions and analyze things like traffic on a certain street in a city or the weather in a certain area.

Big Data Analytics Phase
This phase is used to perform big data analytics over the stored data in blockchain BC DRN .For this task, the authorized cloud server, i.e., CS l performs the standard steps of big data analytics [29].The details of all steps are given below.

•
Secure data collection and processing: Data collection takes on various forms throughout organizations.For example, the data are collected at the CS l in a secure way through the established session key SK GSS k ,CS l , which is further processed and stored in the blockchain BC DRN .Here, it is important to mention that the data stored in BC DRN are protected against various information security-related attacks due to the inherent mechanism of blockchain.

•
Cleaning of data: It is vital to clean the data to improve the findings and raise the bar for the data quality maintained in BC DRN .In order to accomplish this, all of the data need to be presented appropriately, and any redundant or irrelevant material must either be removed or accounted for.Incorrect data can distort the picture and give the wrong impression, which ultimately leads to incorrect insights [29].

•
Secure data analysis: This takes time to transform massive amounts of data into a form that is usable.When it is ready, advanced analytic techniques are able to turn massive amounts of data into insightful conclusions, i.e., the data maintained in BC DRN .The following strategies can be used for analyzing huge data, i.e., "data mining, predictive analysis, and deep learning [30]".Here, data mining is the process of searching through huge datasets to find patterns and relationships.This is accomplished by locating outliers and forming data clusters.Furthermore, an organization's historical data are used in predictive analytics to create forecasts about the organization's future and detect emerging dangers and opportunities.Furthermore, deep learning is a type of earning method that imitates how humans learn by layering algorithms and combining artificial intelligence and machine learning to uncover patterns in the most complex and abstract data [29].
Remark 1 (User authentication process in SBBDA-IoD).The SBBDA-IoD includes a provision stating that a legitimate user may access the data of the network by following the procedures of a standard user authentication protocol (also known as the "secure key management and user authentication scheme" given in [31]).This provision is included in the document.Following the effective completion of each step in this protocol, both the legitimate user (i.e., U m ) and the cloud server (CS l ) will be able to generate a session key SK U m ,CS l in order to gain access to the data in a safe manner.Therefore, U m is able to obtain the data of the network in a safe manner and can utilize it in accordance with their needs.
Remark 2 (Secrecy of the data is maintained in SBBDA-IoD).In the proposed SBBDA-IoD, the messages like msg 1 = {M 1 , M 2 , T 1 }, msg 2 = {M 3 , M 4 , T 2 } and msg 3 = {M 5 , T 3 } are transmitted between DR i and DR j .Similarly, messages like MSG 1 = {TOT DR i , m 1 , m 2 , t 1 }, MSG 2 = {m 3 , m 4 , m 5 , t 2 }, and MSG 3 = {m SKV , t 3 } are exchanged between DR i and GSS k .These messages are constructed through concatenation, bitwise XOR, and cryptographic one-way hash operations.Through these operations, we protect sensitive data during the transmission of these messages.Furthermore, the data which are stored over the cloud servers is maintained in the form of certain blocks of the blockchain.This blockchain is formed through a certain number of blocks, and each block contains sensitive data in the form of encrypted transactions (i.e., TR Therefore, the secrecy of the data are maintained both in transit as well as in storage.
To provide the readers with a better understanding of the paper, we have provided a block diagram of the proposed SBBDA-IoD in Figure 2.This provides an illustration of all phases of the proposed SBBDA-IoD.

Security Analysis of SBBDA-IoD
The security analysis of the SBBDA-IoD is covered here.The security analysis of the proposed framework has been conducted in an informal way through mathematical assumptions and equations and through formal security verification using the Scyther tool (Section 6).Through the conducted security analysis, it has been observed that the proposed framework is secured against various potential attacks, i.e., replay attack, man-inthe-middle (MiTM) attack, impersonation attacks, privileged insider attack, stolen verifier attack, physical drone capture attack, ephemeral secret leakage (ESL) attack, secret data leakage attack, etc. Herein, the specifics are laid down.

SBBDA-IoD Prevents the Replay Attack
Several distinct timestamp values, such as T 1 , T 2 , T 3 , t 1 , t 2 , and t 3 , are utilized and then validated on the opposite end of the communication.If the verification of the timestamp is successful, the recipient will accept the message; if it is not, the message will be denied.The SBBDA-IoD has the capability to prevent replay attacks thanks to the utilization of this condition checking.As a result, the SBBDA-IoD protocol is protected from replay attack.

SBBDA-IoD Prevents Man-in-the-Middle (MiTM) and Impersonation Attacks
We use a variety of proprietary factors, such as (k DR i , k CRA , k GSS k , and k CS l ), in the process of computing the messages that are being broadcast.A does not know these confidential values.Under those circumstances, A cannot make any changes to the delivered or received communications.In addition, A is unable to generate completely novel messages in the forms in which they were initially sent.Because of this, the SBBDA-IoD that is being described provides protection against man-in-the-middle (MiTM) attacks as well as impersonation attacks.

SBBDA-IoD Has Resilience against the Privileged Insider Attack
After registration, CRA deletes the secret values of the entities (k DR i , n DR i , k CRA , K GSS k , RTS DR i , RTS GSS k and k CS l ) from its database, making it inaccessible to the privileged insider user (i.e., A) who plans to harm the entities (i.e., by some attacks).As a result, the SBBDA-IoD is protected from privileged attacks as well as other linked threats such as MiTM attacks, efforts to impersonate someone else, unauthorized session key computations, and so on.As a consequence, the SBBDA-IoD possesses the ability to reduce the impact of the privileged insider attack.

SBBDA-IoD Is Protected from Stolen Verifier Attack
In the secure section of the cloud server database, we maintain records of the parameters that various servers and devices register (i.e., their secret information).Multiple levels of security are used to secure that.Under these circumstances, A is unable to gain access to the entities' secret values.As long as this mechanism is in place, the AKM-BDSF cannot be attacked using the stolen verifier attack or other related attacks.Thus, the AKM-BDSF is secured against the stolen verifier attack.

SBBDA-IoD Prevents Physical Drone Capture Attack
The SBBDA-IoD prevents sensitive information being saved in its unencrypted form in the memory of the drones.In addition, if A physically steals a drone and then attempts to use a sophisticated power analysis attack to retrieve critical data from the drone's memory, this is a very dangerous scenario [25].A would only be able to obtain the drone's session key and registration data under those conditions, but not the secret data of any other drones.Each session key is unique in the SBBDA-IoD.Since each one is computed using a different set of parameters, both of these are kept a secret.It is impossible to figure out the session key for other drones utilizing the deduced session key.As a direct consequence of this, the remaining sections of the transmission are kept secure.Hence, SBBDA-IoD is resistant to an attack that involves the physical acquisition of drones.

SBBDA-IoD Supports Anonymity and Untraceability Properties of Communication
In the SBBDA-IoD, no identifying information is transmitted in plaintext.This ensures that everyone's privacy is preserved.All of the information exchanged is derived from freshly generated timestamp values and randomly generated secret values.As a result of this mechanism's implementation, we obtain different messages in separate sessions.Hence, SBBDA-IoD boasts characteristics like anonymity and untraceability.

SBBDA-IoD Is Secured against Ephemeral Secret Leakage (ESL) Attack under the CK-Adversary Model
The mechanism that makes up the SBBDA-IoD is responsible for computing the session key by making use of both short-term information, such as random nonce metrics, and longterm information, such as secret keys and identities.In SBBDA-IoD, session key between DR i and DR j and DR i and GSS k are calculated as SK DR i ,DR j = h(h(rv . The session keys accommodate both the random secrets (rv DR i , rv DR j , rs 1 , and rs 2 ) as short-term secret values and secret keys (k DR i , k DR j , k CRA , and k GSS k and several identities (RID DR i , RID DR j , and RID GSS k ) as longterm secret values.A fresh session key is generated at the beginning of each session.In this particular scenario, A does not possess the necessary skills to unearth the long-term and short-term secrets, both of which are vital components for precisely establishing the value of the session key.As a direct consequence of this, an adversary will be unable to correctly guess the session key.Therefore, according to the CK-adversary model, SBBDA-IoD is resilient enough to withstand an ESL attack.

Formal Security Verification of the SBBDA-IoD Using Scyther Tool
This section discusses the formal security verification performed for the SBBDA-IoD.It is possible to utilize the Scyther tool in order to validate the formal security of the SBBDA-IoD [32][33][34].It is an upgraded and more effective tool for judging, verifying, and analyzing the specified security protocol than other verification tools that are currently accessible, such as ProVerif and AVISPA.The most advanced cryptographic assumptions were used to develop Scyther.This ensures that an adversary is unable to decrypt the information in the given scheme if they do not have access to the secret key.It does this by imitating user-defined security protocols through the use of a language called security protocol descriptive language (SPDL).Each communication party (entity) is shown as a separate role within the context of the SPDL standard.These roles are able to carry out a variety of tasks, including sending and receiving of messages, the providing the necessary security claims, and the management of events.For example, "send" refers to the act of transmitting a message from one entity to another, while "recv" refers to the act of "receiving" a message from one entity to another [35].
The Scyther tool adheres to the guidelines established by the Dolev-Yao (DY) model in addition to nine additional adversarial models, including the e Canetti-Krawczyk's (eCK) model and the CK model.Scyther claims that the tests it offers can verify several aspects of security, including agreement, synchronization, poor agreement, and secrecy.In order to simulate the authentication and key agreement phase in the proposed system, we take into consideration the two fundamental responsibilities of DR (which refers to a drone) and GSS (which refers to a ground station server).After that, the SPDL code is utilized in order to put the suggested plan into action.Figures 3 and 4 exhibit the SPDL code snippets necessary to play the roles of a ground station server (GSS k ) and a drone (DR i ), respectively.In conclusion, the analysis and implementation results performed with the help of the Scyther tool are displayed in Figure 5 (under the claim, status, and comments items).Further investigation of the claims indicated that the SBBDA-IoD has protection under the claims covered in the preceding section.As a result, according to the findings of the formal security verification, which has been carried out, it is determined that the suggested scheme is protected against the myriad of possible attacks.

Performance Comparison
In this section, we provide the details of conducted comparisons.We compare the SBBDA-IoD with relevant existing protocols, such as the schemes of Ali et al. [13], Rodrigues et al. [14], Ever [15], and Bera et al.The costs of communication, computation, and critical security and functionality characteristics were compared.The details are given below.

Comparison of Computation Costs
The computation costs of the SBBDA-IoD and the schemes of Ali et al. [13], Rodrigues et al. [14], Ever [15], and Bera et al. [16] are compared.For the comparison, we consider a few notations like T h , T ecm , T eca , T exp , T bp , T f e , T senc/sdec , and T mtp which are "one-way hash function using SHA-256 [25]", "elliptic curve multiplication", "elliptic curve addition", "modular exponentiation", "bilinear pairing", "fuzzy extractor operation" and "symmetric encryption/decryption using advanced encryption standard (AES)-128 [36]", and "map-to-point", respectively.To estimate the rough computation time (in milliseconds), we use the experimental results given in [37]: "T ecm ≈ 13.405 ms, T eca ≈ 0.081 ms, T h ≈ 0.056 ms, T bp ≈ 32.713 ms, T exp ≈ 2.249 ms".It is also considered that T f e ≈ T ecm , T senc/sdec ≈ T h and T mtp ≈ T exp .Table 3 provides the different computation cost values.As can be seen from the data presented in Table 3, the SBBDA-IoD has a significantly lower computation cost than the other schemes already in existence.

Comparison of Communication Costs
We use the following assumptions to calculate the communication costs of different schemes: "identity takes 160 bits", a "random number needs 160 bits", the "hash output when SHA-256 technique takes [38] is 256 bits", and a "timestamp needs 32 bits".For a point on an elliptic curve, there is an assumption P = (P x , P y ), where P x and P y are the x and y coordinates, needing (160 +160) = 320 bits.This is considered as per the fact that "the security fulfills by a 160-bit elliptic curve cryptography (ECC) is almost same as that for a 1024-bit RSA-based public key cryptographic technique [39]".The various communication costs are broken down and compared in Table 4.The information shown in Table 4 makes it abundantly clear that the SBBDA-IoD has fewer costs associated with communication than any of the other approaches that are already in use.

Comparison of Security and Functionality Features
In Table 5, we examine the various systems' levels of security as well as their functional capabilities.The information shown in Table 5 makes it abundantly clear that the SBBDA-IoD provides more functionality features in addition to higher levels of security than each of the existing schemes.Like most of the schemes, however, it does not have important features, i.e., formal security verification using the Scyther tool, ephemeral secret leakage (ESL) attack possibility, presence of dynamic drone/device addition, availability of blockchain-based solution, availability of anonymity and untraceability, and support for big data analytics.: "support dynamic drone/device addition phase"; SnF 12 : "support blockchain-based solution"; SnF 13 : "free from design flaws"; SnF 14 : "anonymity and untraceability"; SnF 15 : "support big data analytics"; : "a scheme is secure or it supports a functionality feature"; ×: "a scheme is insecure or it does not support a functionality feature"; N/A: "not applicable in a scheme".

Practical Implementation
In this section, we provide the details of the practical implementation of the proposed SBBDA-IoD.For the big data analytics procedure, we have taken the "SDOT Collisions All Years" dataset [40].We then identified the chances of the collision of vehicles across various streets in a city.As we know, flying drones can also perform the same task and help us make predictions about the possibility of colliding with different vehicles.In this way, we can save people's lives and protect vehicles from damage.

Implementation Settings and Environment
The details of the various simulation parameters are given in Table 6.We used a 2X Intel(R) Xeon(R) processor with 2.20 GHz.The Google Colab environment was considered as the platform over Ubuntu 18.04.5 LTS operating system.The graphics processing unit (GPU) was 12 GB NVIDIA Tesla K80 along with the 13.34 GB random access memory (RAM).The number of cloud servers deployed was 2. The libraries like Shap, Tensorflow, SKLEARN, and Pandas were utilized.Furthermore, the "SDOT Collisions All Years" dataset [40] used utilized.

Obtained Results
During the implementation, the following results were obtained.

Accuracy Values
Accuracy values for possibilities of different vehicles colliding were calculated for different machine learning algorithms, i.e., logistic regression, random forest, XGBoost, and extra trees.We obtained accuracy values of 98.86, 99.25, 99.68, and 99.83, with the logistic regression, random forest, XGBoost, and extra trees algorithms, respectively.Here, it is important to mention that extra trees provided the highest value of accuracy as it suits these data and the organization of the dataset.Therefore, we obtained the highest accuracy value in this case.Similar results are reported in Figure 6.

F1-Score Values
F1-Score values for possibilities of colliding of different vehicles were calculated for different machine learning algorithms, i.e., logistic regression, random forest, XGBoost, and extra trees.We obtained F1-Score values 0.9850, 0.9914, 0.9968, and 0.9986 with the logistic regression, random forest, XGBoost, and extra trees algorithms, respectively.Here, it is important to mention that extra trees provided the highest value of F1-Score as the extra trees algorithm works well with the organization of the used dataset and makes predictions in a better way.Therefore, we obtained the highest F1-Score value in this case.Similar results are reported in Figure 7.

Severity Distribution
Figure 8 gives the severity distribution for different scenarios.We have different types of collision cases, i.e., injury collision, property damage only collision, fatality collision, and serious injury collision.In the given Figure 8, we can see that we have more than 100,000 cases of "property damage only collision" and more than 40,000 cases of "injury collision".However, other cases of injuries are very few, as compared to these cases.

Scatter Plots
The different scatter plots for various cases are given in Figure 9 (person count versus pedestrian count), Figure 10 (injuries count versus vehicle count) and Figure 11 (person count versus vehicle count).From these scatter plots, it is clear that when we have vehicles between 0 and 10, then we have a high possibility of injuries.Furthermore, we have the highest person count when we have five vehicles.Hence, from this discussion, it is clear that we have more injuries when the number of vehicles lies between 0 and 10.

Conclusions
Security and privacy are the main concerns with communication in an IoD network.A secure blockchain-enabled authentication key management framework with big data analytics for drones in networks beyond 5G applications (SBBDA-IoD) was presented that relied on the authenticated key management paradigm.The detailed network model and the associated threat for SBBDA-IoD were provided.The detailed security analysis, i.e., informal security analysis through mathematical assumptions and equations and formal security verification using the Scyther tool, proved the security of SBBDA-IoD.The comparative analysis shows that SBBDA-IoD outperformed the other schemes regarding superior security and efficiency.The real-world implementation of SBBDA-IoD was also performed to evaluate its effect on several important measures for performance.
One of our goals in the future is to enhance the usefulness of SBBDA-IoD, which is currently being offered with additional capabilities.In addition, we wish to incorporate deep learning into SBBDA-IoD so that we can perform superior data analysis and make more accurate predictions.

Figure 3 .
Figure 3. SPDL snippet for the role of a drone DR i .

Figure 4 .
Figure 4. SPDL snippet for the role of a ground station server GSS k .

Figure 5 .
Figure 5. Results of security verification using Scyther tool.

Figure 6 .
Figure 6.Accuracy values for the possibilities of different vehicles colliding.

Figure 7 .
Figure 7. F1-Score values for possibilities of different vehicles colliding.

Figure 8 .
Figure 8. Severity distribution for different scenarios.

Table 2 .
Notations used in the SBBDA-IoD.RID CRA , and k CRA Identity, pseudo-identity, and secret key of CRA ID DR i , RID DR i , and k DR i Identity, pseudo-identity, and secret key of DR i TOT DR i Temporary one-time identity of DR i RI N DR i A pseudo-identification number of DR i ERP DR i Essential registration parameter of DR i

• RGDR1 :
The CRA generates its identity as ID CRA and secret key as k CRA .It then computes its pseudo-identity as RID CRA = h(ID CRA || k CRA ).Then, CRA generates identity for drone DR i as ID DR i and secret key as k DR i .CRA then computes the pseudo-identity of DR i as RID DR i = h(ID DR i || k DR i || RID CRA ), temporary one-time identity as TOT DR i and an essential registration parameter asERP DR i = h(ID DR i || RTS DR i || k DR i || RID CRA ),where RTS DR i is the registration timestamp value of DR i .CRA again generates a pseudo-identification number for DR i as RI N DR i . •RGDR2: where RTS GSS k is the registration timestamp value of GSS k .CRA also securely shares the registration information of drones, i.e., TOT DR i and RID DR i with GSS k by making use of shared master secret key MK CRA−GSS .
• RGGS2: Finally, CRA stores values like, {(TOT DR i , RID DR i After calculating these values DR i sends the message msg 1 = {M 1 , M 2 , T 1 } to DR j through an insecure channel.• AKADD2: When DR j receives msg 1 from DR i , it first verifies the correctness of T 1 by solving the equation |T 1 − T * 1 | ≤ ∆T, where ∆T is the maximum transmission delay and T * 1 is the time at which msg 1 was received.Then, DR j computes h(rv DR i || RID and another important parameter as M 4 = h(SK DR j ,DR i || RI N DR i || RI N DR j || T 1 || T 2 ).DR j then sends message msg 2 = {M 3 , M 4 , T 2 } to DR i through an open insecure channel.• AKADD3: When DR i receives msg 2 from DR j , it first verifies the correctness of T 2 by solving the equation |T 2 − T * 2 | ≤ ∆T, where ∆T is the maximum transmission delay and T * 2 is the time at which msg 2 was received.DR i then computes h(rv DR j || RID DR j ) = M 3 ⊕ h(RID DR j || T 2 ) and session key as SK DR i ,DR j = h(h(rv DR i || RID DR i )|| h(rv DR j || RID DR j )|| RI N DR i || RI N DR j || N DR i || N DR j || T 1 || T 2 ) and M 4 = h(SK DR j ,DR i || RI N DR i || RI N DR j || T 1 || T 2 ).DR i checks M 4 = M 4 ?If it matches, then DR j is authenticated with DR i , and the computed session key by DR i is correct.Again DR i generates another fresh timestamp value T 3 and computes M 5 = h(SK DR i ,DR j || T 3 ) and sends message msg 3 = {M 5 , T 3 } to DR i via open channel.
• AKADD4: When DR j receives msg 3 from DR i , it first verifies the correctness of T 3 by solving the equation

• AKADG1 :
DR i initiates the process with the generation of a random secret parameter (i.e., a variable) rs 1 and fresh timestamp value t 1 .It then computes m 1 = h(rs1 || ERP DR i || t 1 ) ⊕ h(RID DR i || t 1 ) and m 2 = h(h(rs 1 || ERP DR i || t 1 )|| RID DR i || t 1 ).After that, DR i sends the message MSG 1 = {TOT DR i , m 1 , m 2 , t 1 } to GSS k via open channel.•AKADG2:WhenGSS k receives MSG 1 from DR i , itfirst verifies the correctness of t 1 by solving the equation |t 1 − t * 1 | ≤ ∆T, where ∆T is the maximum transmission delay and t * 1 is the time at which MSG 1 was received.Then, GSS k fetches RID DR i , corresponding to the received TOT DR i .It then computes h(rs 1 || ERPDR i || t 1 ) = m 1 ⊕ h(RID DR i || t 1 ) and m 2 = h(h(rs 1 || ERP DR i || t 1 )|| RID DR i || t 1 ).GSS k then checks m 2 = m 2 ?If it matches, then DR i is authenticated with GSS k .Furthermore,GSS k generates a random secret parameter (i.e., a variable) rs 2 and the fresh timestamp value t 2 .It again computes m 3 = h(rs 2 || ERP GSS k || t 2 ) ⊕ h(RID DR i || t 2 ) and session key as SK GSS k ,DR i = h(h(rs 1 || ERP DR i || t 1 )||h(rs 2 || ERP GSS k || t 2 )|| RID DR i || t 1 || t 2 ).After that, GSS k computes m 4 = h(SK DR i ,GSS k || h(rs 2 || ERP GSS k || t 2 )|| RID DR i || t 2 ) and a new temporary one time identity as TOT new DR i .It again computes m 5 = TOT new DR i ⊕ h(h(rs 1 || ERP DR i || t 1 )|| RID DR i || t 2 ).After that GSS k sends the message MSG 2 = {m 3 , m 4 , m 5 , t 2 } to DR i through an open (insecure) medium.When DR i receives MSG 2 from GSS k , it first verifies the correctness of t 2 by solving the equation |t 2 − t * 2 | ≤ ∆T, where ∆T is the maximum transmission delay and t * 2 is the time at which MSG 2 was received.It again computes h(rs 2 || ERP GSS k || t 2 ) = m 3 ⊕ h(RID DR i || t 2 ) and session key as SK DR i ,GSS k = h(h(rs 1 || ERP DR i || t 1 )|| h(rs 2 || ERP GSS k || t 2 )|| RID DR i || t 1 || t 2 ).After that, DR i computes m 4 = h(SK DR i ,GSS k || h(rs 2 || ERP GSS k || t 2 )|| RID DR i || t 2 ) and checks m 4 = m 4 ?If it matches, then GSS k is authenticated with DR i , and the session key computed by DR i is correct.Again, DR i computes its new temporary one-time identity as TOT new DR i = m 5 ⊕ h(h(rs 1 || ERP DR i || t 1 )|| RID DR i || t 2 ).DR i generates another fresh timestamp value as t 3 and computes m SKV = h(SK DR i ,GSS k || t 3 ).After that, DR i sends message MSG 3 = {m SKV , t 3 } to GSS k through the open (insecure) medium.• AKADG4: When GSS k receives MSG 3 from DR i , it first verifies the correctness of t 3 by solving the equation |t 3 − t * 3 | ≤ ∆T, where ∆T is the maximum transmission delay and t * 3 is the time at which MSG 3 was received.It again computes m SKV = h(SK GSS k ,DR i || t 3 temporary one-time identity as TOT ν DR i and essential registration parameter asERP ν DR i = h(ID ν DR i || RTS ν DR i || k ν DR i || RID CRA ), where RTS ν

Table 3 .
Comparison of various computation cost values.

Table 4 .
Comparison of communication costs.

Table 5 .
A juxtaposition of security and functionality components.

Table 6 .
Details of the simulation parameters.