An Intelligent Hybrid Framework for Threat Pre-Identification and Secure Key Distribution in Zigbee-Enabled IoT Networks Using RBF and Blockchain

Abstract

The expansion of Zigbee-enabled IoT networks has generated significant security issues, especially around threat detection and secure key management. Using RBF and blockchain technology, this study shows a smart hybrid framework to find threats early and distribute keys safely on IoT networks enabled by Zigbee. This methodology incorporates Radial Basis Function (RBF) networks for prompt threat detection and a blockchain-based trust framework for decentralized and tamper-proof key distribution. It guarantees safe network access, comprehensive authentication, and effective key updates, reducing risks associated with IoT-related DoS attacks and Man in the Middle Attacks. The Trust-Based Security Provider (TBSP) enhances security by administering critical credentials across diverse networks. Comprehensive simulations and performance assessments illustrate the effectiveness of the framework in increasing threat detection precision, minimizing key distribution delay, and bolstering overall network security. The findings confirm its efficacy in safeguarding IoT settings from new risks while ensuring scalability and resource efficiency. We proposed an RBF-based threat detection framework for network keys using the ZBDS2023 dataset and the J48 decision tree algorithm. In conclusion, we demonstrate the security and efficiency of our proposed work.

1. Introduction

The proliferation of Internet of Things (IoT) devices has increased significantly recently. The estimated number of active IoT devices in 2019 was approximately 26.6 billion, with a projected increase to 30 billion in 2020, according to SafeAtLast. According to the International Data Corporation (IDC), the number of interconnected IoT devices will exceed 41.6 billion by 2025, resulting in an estimated 79.4 zettabytes (ZB) of data. The need for secure, efficient, and scalable communication protocols has been underscored by the ongoing expansion of IoT ecosystems in a variety of sectors, including healthcare, industrial automation, and smart cities.

Due to its lightweight architecture, low power consumption, and robust scalability, Zigbee is a standout among widely adopted IoT communication protocols. Healthcare monitoring systems, industrial control systems, and smart home automation have widely implemented Zigbee, which is based on the IEEE 802.15.4 standard. It offers a solution for IoT networks that is both energy efficient and cost effective, particularly in environments that require short-range, low-data-rate communication [1]. Despite its numerous benefits, Zigbee suffers from a number of critical security vulnerabilities, including key distribution, authentication, and network integrity. Due to these problems, apps enabled by IoT are at high risk of being hacked or spied on through key compromise, DoS attacks, Man in the Middle Attacks, and other threats.

Key management is a fundamental security concern in Zigbee networks. For network authentication, the protocol depends on a globally shared master secret. If this key is compromised, it can result in unauthorized access and network-wide breaches. Additionally, Zigbee’s cryptographic mechanisms and device limitations make it open to both passive and active attacks, which means that the current security system can be broken into. Attacks like the Philips Hue malware exploit and others in the real world have shown that attackers can get into and control whole smart lighting networks by using broken key distribution mechanisms. Additionally, these security risks are further exacerbated by the absence of secure authentication methods and robust end-to-end encryption.

In order to overcome these obstacles, this paper suggests the integration of Radial Basis Function (RBF) networks and blockchain technology to create an Intelligent Hybrid Framework for Threat Pre-Identification and Secure Key Distribution in Zigbee-Enabled IoT Networks [2]. The RBF network, a specialized form of artificial neural network, is employed for anomaly detection, allowing for the real-time identification of potential security hazards prior to their ability to corrupt the network. Simultaneously, blockchain technology guarantees decentralized and tamper-proof key management, thereby eradicating single points of failure in key distribution processes. When these two technologies are combined, they make Zigbee-enabled IoT networks stronger against cyber threats. This also makes sure that security operations are scalable and effective.

The proposed framework introduces a Blockchain Security System (BCS) that is trust-based and enables the secure distribution of cryptographic credentials across Zigbee-enabled IoT devices. The framework improves the security of key storage by utilizing physically unclonable functions (PUFs), rendering it resistant to unauthorized duplication and replication. Furthermore, it can support secure network joining, key distribution across the whole network, key updates, and access control mechanisms, ensuring a complete security plan for IoT applications.

Our approach makes Zigbee networks more secure by combining blockchain-based key management with RBF-based threat intelligence. This lowers the risks that come with using regular key distribution methods. This mixed security model makes sure that large-scale deployments work well and can talk to each other. It also keeps IoT devices safe from new cyber threats.

We organize the remainder of our work as follows. Section 2 covers Zigbee-enabled IoT network security issues and existing solutions. Section 3 presents the preliminaries and background used in the proposed trusted BCS. Section 4 explains the operation and architecture of the proposed hybrid security system and discusses the experiment setup and system evaluation criteria. Section 5 presents the results and performance analysis, proving that the approach works. Section 6 concludes the analysis and offers further research.

The main contributions are as follows. Here is a summary of our proposed framework’s notable research contributions: This paper presents the proposed work for a trust-based BCS to distribute keys among Zigbee-enabled IoT devices. This paper provides the following solutions for the above challenging issues:

• We proposed a novel hybrid security framework that integrates Radial Basis Function (RBF) networks and blockchain technology to enhance security in Zigbee-enabled IoT networks.
• We have developed an intelligent threat pre-identification system using RBF-based machine learning models to detect and classify security threats in real time, thereby improving proactive defense mechanisms.
• We designed a trust-based key distribution mechanism that leverages blockchain for decentralized, tamper-proof, and resilient key management among IoT devices.
• We set up a trust management system based on blockchain to make sure that communications in Zigbee-enabled smart networks are authentic, correct, and cannot be disputed.
• We designed a lightweight blockchain architecture and optimized computational and communication overheads for IoT devices with limited resources. This made the system more scalable and energy efficient.

2. Related Works

This section provides a literature review of current research on consortium blockchain systems for securing Zigbee-enabled IoT networks. This is due to the numerous security issues that arise when transmitting IPv6 packets across IEEE 802.15.4 Zigbee networks. It is difficult to make sure that a new device’s link to a network is real and that the network key is sent safely from the administrators to the device. The following comments are among the most pertinent found in the prior literature. The implementation of a gateway via a Zigbee coordinator enhances the security of communications between Zigbee nodes and Internet hosts.

A significant obstacle with IPv6 via Zigbee is the restriction on packet size, since Zigbee devices can accommodate a maximum data unit of 127 bytes, but IPv6 packets need a minimum of 1280 bytes. Zigbee functions inside personal area networks and uses routers to relay IPv6 packets across IEEE 802.15.4 networks. Zigbee devices are incapable of directly processing IPv6 packets; hence, gateways and Zigbee coordinators must execute the neighbor-finding operation. Zigbee networks also use cutting-edge routing protocols like “Ad hoc On-Demand Distance Vector” (AODV), which limits network speed, resources, and packet loss. The route discovery process still possesses significant network overhead. However, many Zigbee devices lack such an interface due to their limitations.

Ender Yuksel et al. [3] proposed the fundamental security provisions of the most current Zigbee specification, Zigbee-2007. They learned more about the math behind methods like SKKE, CBKE, and MEA for authentication and key establishment. They also learned about the important protocol descriptions like “Authentication”, “NK Update”, and more. Their author defines the key ideas, computations, and protocols and creates them using standard protocol narratives. These mostly talk about authentication features and come to the conclusion that pre-deployed key mechanisms, “symmetric key” agreements, and ECC-based algorithms are now the most common ways to authenticate in a Wireless Sensor Network. The author anticipates that the wide range of applications for Zigbee will require a lot more work in Zigbee security and intends to examine and confirm the security protocols for Zigbee.

Don Sturek et al. [4] proposed using networking standards set by the IETF and based on IEEE 802.15.4; the Zigbee IP specification creates a standard, interoperable protocol stack for wireless mesh networks. The protocol stack specification indicates compatibility for Smart Energy Profile 2.0 applications and other Zigbee applications that use the Zigbee IP stack. This specification meets the technical requirements outlined in the Smart Energy Profile 2.0 Technical Requirements Document [SE-TRD]. Occasionally, nodes send and receive MLE messages before they join the network and establish secure links with their neighboring nodes. The MLE protocol independently protects its payload, since MLE communications are not consistently reliant on MAC security.

Ghada Glissa et al.’s [5] proposed Secure-RPL (SRPL), a secure routing protocol built on RPL to enhance data transportation in 6LoWPAN-based IoT networks. Aimed at countering internal threats, SRPL introduces a rank threshold mechanism and hash chain-based authentication to prevent malicious nodes from altering control message values such as node rank, which can disrupt network topology. The protocol is designed to mitigate attacks like sinkhole, black hole, and selective forwarding. Simulation results demonstrate that SRPL significantly improves resilience against such malicious manipulations while maintaining efficient routing performance.

Mostafa Yavari et al. [6] also proposed the IBCbAP, a better blockchain-based authentication protocol with anonymity and secure access management. Using the local Ethereum blockchain and the JavaScript programming language, we implemented the IBCbAP. Blockchain, essentially an anti-hacking, distributed, and event-logging mechanism, seems very helpful for resolving important issues related to networks where connected devices automatically interact with each other, or IoT. The importance of IoT security has led to the development of numerous plans in this field. The author also suggested a better protocol called IBCbAP and demonstrated its security informally and formally using the Scyther tool to address the security.

Weicheng-Wang et al. [7] presented a new Zigbee joining protocol built on cheap public-key primitives without needing certificates. The new protocol consists of two parts. Firstly, the ECDH key exchange extends the current association request/response messages to improve user device privacy. Therefore, the main goal is to create a mechanism that enhances the security of the current protocol while adhering to the packet size limit and doing so without adding any new procedures or messages. The author proposes two cryptographic improvements to the Zigbee security protocols and then implements and tests the suggested protocols. The author’s evaluations also offer compelling evidence that these improvements are both doable and successful in fending off both passive and active attackers.

Bernardo David et al. [8] proposed a blockchain-based incentive system for Tor’s partially decentralized anonymous routing network nodes. These issues make the current reputation systems less accurate and useful. These systems use complicated heuristics to reduce false accusations of wrongdoing and give all honest nodes the same reputation impression. The solutions also included financial incentives, urging the creation of a “central bank” entity that compensates nodes for participating in routing.

Chi Ho Lau et al.’s [9] proposed solution can be implemented in the existing network without requiring significant changes to the communication standards. Blockchain technology authenticates IoT devices before their network integration, enabling digital identity via blockchain attributes. The authentication process is executed using the Authenticated Device Configuration Protocol. A detailed discussion of the system’s design and mechanism has taken place to demonstrate the solution’s viability. The solution’s conclusions are supported by a fully functional implementation rather than just theoretical arguments or computer simulations. We compared the existing solutions with our proposed framework in the following

Table 1. Comparative analysis of existing solutions.

Ref.	A	B	C	D	E	F	G	H	I	J	K	L	M	N
Ender Yuksel, Nielson [3]	×	×	×	×	×	×	✓	✓	✓	✓	×	✓	×	×
Sturek, Don et al. [4]	×	✓	×	×	×	✓	✓	✓	×	×	×	✓	×	×
Glissa, Ghada and Rachedi et al. [5]	×	✓	×	×	×	✓	✓	✓	×	×	×	×	×	×
Yavari, Mostafa and Safkhani et al. [6]	×	×	×	×	✓	×	✓	✓	✓	×	✓	✓	×	×
Wang, Weicheng, and Cicala et al. [7]	×	×	×	×	×	×	✓	✓	✓	✓	✓	✓	×	×
Kiayias, Aggelos et al. [8]	✓	×	×	×	✓	×	✓	✓	✓	×	×	✓	×	×
Lau, Chi Ho and Alan et al. [9]	×	×	×	×	✓	×	✓	✓	×	✓	×	✓	×	×
Ghada Glissa et al. [10]	×	×	×	×	×	✓	×	✓	✓	×	✓	×	×	×
B. Priyeash, J. Thyagarajan et al. [11]	✓	✓	×	×	×	✓	×	×	×	×	×	×	×	×
Tanveer, Muhammad et al. [12]	×	×	×	×	×	×	✓	✓	×	✓	×	✓	×	×
Proposed Mechanism	✓	✓	✓	✓	✓	✓	✓	✓	✓	✓	✓	✓	✓	✓

A = AODV routing protocol, B = RPL routing protocol, C = RPL-AODV routing protocol, D = Routing Attacks, E = blockchain, F = 6LoWPAN, G = Security, H = Authentication, I = Key Agreement, J = Trust Center, K = Lightweight Property, L = Access Control, M = Routing Optimization, N = Zigbee Network Key Sniffing Attacks

.

Ghada Glissa et al. [10] proposed a new security protocol known as “6LowPSec”. It acts at the adaptation layer yet offers a great end-to-end security solution. 6LowPSec uses the hardware security characteristics defined by the MAC security sublayer. We present a detailed campaign that compares the performance of 6LowPSec to the lightweight IPSec. The results show that an end-to-end hardware security solution for IoT that works at the adaptation layer with little extra work is possible.

B. Priyeash et al.’s [11] “wireless sensor network” is called a “low-power and lossy network”. These networks have limitations in terms of memory, power, size, etc. Devices placed in these networks must be tuned to carefully consume the least amount of resources possible for an extended period. Occasionally, people set up these networks in locations where regular human interaction is impossible. It is crucial to choose the correct routing protocols for these low-power devices. The “ad hoc on-demand distance vectors” and “low-power and lossy networks” routing protocols are two important ones.

Muhammad Tanveer et al. [12] introduced REAP-IIoT, a resource-efficient authentication protocol tailored for the Industrial Internet of Things (IIoT). The protocol leverages Lightweight Cryptography (LWC), specifically the AEGIS AEAD primitive and hash functions, to enable secure and efficient mutual authentication between smart devices (SDs) and users. REAP-IIoT establishes a session key (SK) for encrypted communication while ensuring privacy preservation and resistance against attacks such as replay and man-in-the-middle. The protocol’s security is validated using the real-or-random model, Scyther verification, and informal analysis, demonstrating robust protection with low computational, communication, and storage overheads—making it highly suitable for resource-constrained IIoT environments.

3. Background Work

Preliminaries and Basic Building Blocks. This section outlines the Zigbee IP protocol stack architecture, which is the foundation for the proposed trustworthy BCS’s cryptographic primitives.

3.1. Zigbee IP Protocol Stack Architecture

This section discusses the architecture of the Zigbee IP protocol stack, as illustrated in Figure 1. It is made up of “the IEEE 802.15.4 standard”, the Zigbee IP alliance, and applications [13]. “The IEEE 802.15.4 standard” consists of 802.15.4 PHY and link layer 802.15.4 MAC. Zigbee IP Alliance provides a network adaptation layer, a routing layer, a transport layer, an application support sublayer, a service provider, and an application layer. When sending IPv6 packets across Zigbee networks, the IEEE 802.15.4 standard performs the necessary tasks and offers the facilities required. The IEEE 802.15.4 PHY layer provides services to the top layer, including modulation and demodulation of different transmitted and received signals, energy detection, connection quality indicator, channel selection, and clear channel evaluation. The link layer of “IEEE 802.15.4 MAC” is responsible for creating beacons and synchronizing the device (collision-free, CSMA/CA). Frame buffering and polling methods are used for frame transfer, encryption, authentication, and response protection. The 6LoWPAN protocol is the next layer in the protocol stack, acting as an adaptation layer to deliver services to the internet layers. This protocol transports data from Zigbee end devices across the MAC and PHY layers to the top layer. The 6LoWPAN protocol provides several services, including neighbor discovery in the top layer, fragmentation, reassembly, stateless autoconfiguration, and header compression. IoT devices that use Zigbee can talk to IPv6 nodes through the 6LoWPAN protocol, which handles the larger payload. The maximum frame length for IEEE 802.15.4 is 127 bytes, and the maximum transmission unit for IPv6 is 1280 bytes [14,15].

The network layer provides a wide range of services to the Zigbee-enabled IoT devices, including IPv6 addressing, packet framing, messaging through ICMPv6, neighbor discovery, and duplicate address detection. Further, this layer propagates 6LoWPAN configuration information and forwards IPv6 packets and multicast. The Internet Control Message Protocol for IPv6 is a fundamental IPv6 protocol that reports errors and data generated during packet processing using error or informational messages. Link-local scoped multicast is used by “Neighbour Discovery” and other IPv6 parts to find routers, find duplicate addresses, and resolve addresses. “Stateless address autoconfiguration” simplifies IPv6 device configuration and maintenance by allowing nodes to provide meaningful addresses. The routing layer uses the AODV-RPL protocol. It is a reactive peer-to-peer route discovery protocol that can find routes for both symmetric and asymmetric network traffic [16]. This routing system allows for point-to-point communication between 6BRs and Zigbee devices, as well as multipoint-to-multipoint transmission from Zigbee devices to 6BRs. DODAG, a destination-orientated directed acyclic graph with a root-based design, manages diverse traffic flows. The management function, which is the application support sublayer, is in charge of the different protocols so that the node can do what it needs to do. The application support sublayer offers services to the application and network layers [17,18]. The application support sublayer is in charge of node bootstrapping, node power management, non-volatile storage, and restoration of critical network parameters. The definition for various application profiles employing application layers will be included in the application layer, letting users take on the burden of developing applications. The application profile specifies the over-the-air communication mechanism. Communication across devices is possible if they have the same application profiles. This part presents the preliminary information and fundamental building elements needed for the proposed system. We then cover the architecture, design, and assumptions of the system that support our work.

3.2. Cryptographic Primitives Used in Proposed Work

Elliptic curves over finite fields are the foundation of Elliptic Curve Cryptography (ECC), a technique for public key cryptography (PKC), which is used in this part to secure our suggested system. Compared to PKC, ECC employs more small keys while keeping the level of security the same. This enables encryption and decryption techniques to be used by “Zigbee devices (ZDs)” with little memory and computing capacity. In our proposed system, digital signatures and key negotiations are denoted by “ECC”. The Zigbee coordinator will make “the public–private key” pair available to edge devices via ECC to let them sign messages and blocks published in the anticipated BCS. The suggested “blockchain architecture” employs the “Elliptic Curve Digital Signature Algorithm (ECDSA)”, a PKC technique that guarantees the authenticity and integrity of communications sent from fog nodes to edge devices. Before adding blocks, the distributed ledger verifies them using a threshold digital signature technique.

3.3. ECDSA Signature Scheme

Consider the EC $E:y^2+ax+b$ where $Zp$ is a finite field, $b\in Zp$ and $4a^3+27b^2\ne 0$ is a generator of prime order $\prime n\prime$, where $G\in E\left(Z_p\right)$. “The ECDSA” algorithm makes use of the hash function $H:Me\to Z_p$. Messages are inserted into fields that start with $“p”$ in this manner. The three practical algorithms that make up the ECDSA Signature Scheme are as follows:

3.3.1. Key Generation Algorithm

A point on the EC and an integer are used as the private key $PrivK$ and public keys-$PubK$, respectively, in the “ECDSA” key-pair: $PubK=PrivK\ast G$.

• $PrivK$ is a [0…$\mathit{n}$ − 1] random integer.
• $PubK\in EC$ point multiplication used to calculate the EC—$PubK=PrivK\ast G$.

3.3.2. Sign Algorithm

The message ($Me$), private key $PrivK$, and a signature $(q,t)$ are the input and output, respectively, of the ECDSA Sign algorithm. The ECDSA Sign algorithm employs the ElGamal signature technique, which functions as follows:

• $h=Ha\left(me\right)$—Using a cryptographic hash algorithm, determine the message’s hash value.
• Securely produce the random integer ’l’ $\in [1\dots n-1]$
  . $Ra=l\ast G,q=Ra.x$—Determine the x-coordinate of the random point.
• $t=l-1\ast (h+q\ast PrivK)\left(modn\right)$—the signature proof calculation.
• Output $q,t.$

Here, $[1\dots n-1]$ is the range for the integers $q,t.$ The random point is encoded using the Sign technique. $Ra=l\ast G$, along with a proof t, demonstrates that the signature is knowledgeable of the message and the private Key $PrivK$. The Public Key, $PubK$, may be used to validate the proof t’.

3.3.3. Verify Algorithm

The signed message is used as the input for the ECDSA Verify Algorithm. ‘m’ is the ECDSA Sign algorithm’s signature of the form q, t, and the signer’s public Key $PubK$, which is matched to the signer’s private Key $PrivK$. A valid or incorrect value is the output. As seen below, the ECDSA verification algorithm follows:

• $h=Ha\left(m\right)$—compute the message’s hash.
• $sig=s-1\left(modn\right)$—the inverse modular proof of the signature.
• $R^{\prime }=(h\ast Si)\ast G+(q\ast Si)\ast PrivK$—recovering the signing-related random point.
• $q^{\prime }=R^{\prime }.x$—Determine R’s x-coordinate.
• If $q’==q$, it is a genuine signature.

3.4. Attacks on the Zigbee Network

Here is a summary of the most common attacks in Zigbee networks:

• DoS Attack This attack may put a victim device on an unending retransmission cycle.
• Zigbee Network Key Sniffing Attack Vulnerability in the key transport of the Zigbee network while using the minimum security level.
• Network Discovery and Device Identification Attack Zigbee devices send beacon request frames on a specific channel during the network discovery process. ZR and the coordinators will react by exchanging some important information.
• Interception of Packets Attack Possibility of an attacker listening in on Zigbee network traffic and using the information they obtain
• Command Injection Attack An attacker can take control of target devices by impersonally dating simple machines after obtaining the network key.
• Hijacking via Network Key Update Attack The target node can be forced to change its network key to a value of its choosing by an attacker posing as a Zigbee coordinator.
• Worm Attack This novel attack can disable the smart lighting system for an entire city and set off a chain reaction that renders bright lights useless.
• IoT Worm Hack on Philips Hue Light Bulbs In November 2016, researchers published an attack against Philips Hue Light Bulbs, demonstrating the use of Zigbee standards. Attackers utilized a Philips hue light drone and infected the light bulbs with a worm/virus to enable and disable attackers. Funny enough, the assailants were checking the lights and flashing an ”SOS” Morse code. This technique drives them through the Zigbee network using hardcoded symmetric keys from the light bulbs. The worm may attack a light bulb from a distance of up to 400 m and spread to neighboring amps because Zigbee utilizes hard-coded skeleton keys. The worm led Philips to provide an automated firmware upgrade for the lights and to circumvent built-in security protections to prevent unwanted remote access. Then, the attackers could quickly decipher the AES-CCM key used in all hue light bulbs. Zigbee can then extend the worm to nearby bulbs.

4. Proposed Work

This section introduces an advanced hybrid architecture that integrates Radial Basis Function (RBF) networks with blockchain technology to improve security, facilitate efficient key distribution, and allow proactive threat detection in Zigbee-enabled IoT networks [19]. The proposed approach utilizes the trust-based blockchain system (pBCS) to securely distribute keys across Zigbee-enabled IoT devices. Blockchain: The “Trust Security Service Provider (B-TSSP)” is the proposed BCS. All Zigbee-enabled IoT devices are safe because the same cryptographic credentials are used on the Zigbee edge device with trusted storage across the Zigbee IP protocol stack. This capability is achieved through a physically unclonable function (PUF) mechanism, as illustrated in Figure 2. The trusted blockchain will create the signed certificates using a private validator key commonly used as a root of trust. Before performing any operations, all Zigbee coordinators, routers, and end devices must enroll with a BCS. The Zigbee IP Coordinator is the full-function device that can initiate a new Zigbee network and maintain the blockchain system. As per Zigbee alliance specifications, there must be a single coordinator for each Zigbee network. The end user will communicate with any ZED only through the Zigbee IP Coordinator when an existing Zigbee network needs to accommodate the addition of a new end device. Then, the user must change the network’s status through Blockchain DApps from a closed to open state and send the exact request (open state) command to the coordinator. Then, the smart contract of the blockchain system will verify the state and change the system’s state. When the Zigbee network switches to an open state, the coordinator authorizes the broadcast of a join response message, telling all ZD that the network is now accepting new joining requests and is in an open state. On the other hand, the Zigbee network cannot take any new devices once it has reached a closed state. Only the Trusted Permissioned Blockchain can create authentically signed certificates [20,21].

Any router or Edge device that holds the validator’s public key can validate the signed certificate and guarantee the public key’s integrity. Lastly, the Secure Communication Protocol transfers data between the ZED and the coordinator through a registered ZR. This secure communication protocol derives the shared secret key between the coordinator and edge devices in the untrusted field, authenticated and encrypted communication. In this secure communication protocol, we performed mutual authentication with less non-volatile memory (ROM). Before performing the mutual authentication, the BCS must enroll the blockchain validator and ZED. This proposed BCS solves the problem of less usage of non-volatile memory and improves key management. The blockchain validator will access the shared ledger that stores the digital key credentials of all the enrolled ZED and Zigbee Routers (ZR), including the Zigbee Coordinators.

The proposed Zigbee IP protocol stack security architecture, is made up of “Zigbee IP alliance security” and “applications security”. The link layer (MAC) and PHY (802.15.4) security are supported by the IEEE 802.15.4 standard. The Zigbee IP alliance offers network adaptation layer security, network layer security, routing layer security, transport layer security, application support sublayer security, application layer security, and blockchain service providers.

Blockchain—The Trust Security Service Provider: The proposed blockchain system, called Blockchain: The Trust Security Service Provider (B-TSSP), provides an open trust model that allows end-to-end security among IoT-enabled Zigbee devices by reusing the same cryptographic credentials among the Zigbee IP protocol stack on the same Zigbee edge device. In other words, this proposed BCS provides the trust security service to the Zigbee IP protocol stack. By providing many security services, the B-TSSP makes the security procedures possible. These include creating an end-to-end application key, leaving a secured network, joining a secured network, distributing network-wide keys, updating network keys, managing network access and authenticating routers and end Zigbee devices, keeping frames safe, storing key credentials, and restoring important security and network configuration data. It also has security mechanisms for the Network APS Security sublayer. Figure 3 shows the proposed Zigbee IP protocol stack security with an attack landscape.

Physical Layer Security (PHY) confronts several obstacles, and typical wireless physical layer security solutions are difficult to implement in Zigbee contexts [22]. Most Zigbee devices have modest data rate needs, periodic data traffic arrivals, minimal hardware, signal processing capabilities, and sensor levels. Various aspects must be considered, including multi-path effects, fading, unpredictability, the sensors’ geographically scattered nature, and heterogeneity. Furthermore, basic PHY assumptions include the adversarial model, the heart of the wireless channel, and practical considerations during implementation. As the IEEE 802.15.4 standard implies, PHY offers no security services. Additionally, communication devices must often share a standard secret key to use upper-level security services. A pre-shared private key is already pre-installed on each device on the network. PHY should work with upper layers to provide various security levels if security services are requested. Secure communication between Zigbee devices is made possible by the security of the IEEE 802.15.4 MAC layer protocols. The medium access control: These MAC layer protocols use AES-CCM encryption to maintain data integrity and guarantee data secrecy. The most commonly used technique for encrypting data on the MAC layer is AES. MAC layer protocols offer decent security services. However, certain important issues remain unaddressed. People typically view MAC layer security as more secure than the upper layers because it may safeguard MAC layer data and higher layer headers. Enabling MAC layer security eliminates the need for deposits at higher levels. Adaptation Layer Security: The adaptation layer facilitates communication between the network and internet layers by consolidating data from endpoint devices. Figure 2 shows that IPv6 needs a transmission unit of at least 1280 octets, but IEEE 802.15.4 limits the largest Zigbee MAC frame size to 127 bytes, which includes 25 bytes of frame overhead and only 102 bytes of content. Presume the link layer incorporates a security header into the MAC frame for security purposes. In the most unfavorable circumstance, the supplementary header size permits just 81 bytes for the IPv6 packet. A Zigbee frame is incapable of containing an IPv6 packet. Moreover, the top layers measure just 41 bytes, as the IPv6 header of an IPv6 packet is 40 bytes in length. Application data are sent using either the 8-byte User Datagram Protocol (UDP) header or the 20-byte Transmission Control Protocol (TCP) header, which are both part of the IPv6 header. The adaptation layer utilizes the “IPv6 over Low- Power Wireless Personal Area Networks” (6LoWPAN) protocol, enabling communication across all Zigbee-enabled sensor nodes over IP. The 6LoWPAN protocol facilitates direct communication between Zigbee IoT devices and Internet hosts [23,24]. Upon receiving a request from the internet host or end user, the 6LoWPAN protocol executes three fundamental services: The 6LoWPAN protocol uses fragmentation and reassembly to meet the minimum MTU requirements of IPv6. Header compression removes potentially inferred information from link-level data or establishes common contextual assumptions. Link-layer forwarding enables the transfer of IPv6 datagrams over several hops. The Network Layer Security offers an extensive array of services for Zigbee-enabled devices.To protect an “NWK layer” frame, the Network Layer Security uses “AES encryption/authentication” with the Enhanced Counter and the “CBC-MAC (CCM*)” mode (the “NWK layer” ensures the security of transmitting and receiving outgoing and arriving frames). The highest levels oversee security processing processes by generating security keys. The routing layer: The routing layer uses the AODV-RPL protocol, which is a reactive “peer-to-peer” route discovery system that can find routes for both symmetric and asymmetric network flows. It is a “routing protocol” that facilitates point-to-multipoint communication from a 6BR to Zigbee devices and “multipoint-to-multipoint” communication from “Zigbee devices” to a 6BR. A destination-oriented, directed acyclic graph with a root-based design manages diverse traffic flows (DODAG).

The DTLS protocol, which stands for Datagram Transport Layer Security, is based on the TLS protocol and can offer similar security guarantees while maintaining the datagram delivery model. DTLS provides authenticity, including “data origin authentication”, “identity authentication”, “integrity”, and “confidentiality”. DTLS operates on top of the “unreliable transport protocol UDP”. PANA and EAP use DTLS to authenticate a joining node and the “Authentication Server”. The Application Support (APS) Sublayer. Through a wide range of services provided by APS data and management entities, the “Application Support (APS)” sublayer serves as an interface between the NWK and APL levels. The APS sublayer handles incoming and outgoing frames to establish and manage the cryptographic keys and allow safe transmission and reception of the frames. The APS sublayer receives primitives from the above levels to access its services. Entity Authentication, Permission Config Table, Establish Key, Transport Key, Updating Device, Removal Device, Request Key, Switch Key, and Device Update and Removal are among the services that make up APS Layer Security. The support for application security protocols, service discovery protocols, encryption methods, and authentication procedures is integrated to provide sublayer security. The Application Layer Security. This layer provides direct end-to-end security at the application level. As shown in Figure 3, the Constrained Application Protocol is one of Zigbee’s most well-liked application layer protocols (CoAP). The Internet Engineering Task Force’s working group on constrained RESTful environments (CoRE) has suggested CoAP (IETF). However, the CoAP does not offer any security services. To protect CoAP messages concerning secrecy, integrity, authentication, and non-repudiation, it integrates with DTLS. CoAP defines four security levels that differ in the methods used for key negotiation and authentication.

A hybrid security architecture using RBF networks and blockchain can improve Zigbee-enabled IoT network security. RBF networks ensure data integrity, authentication, and confidentiality for proactive threat identification, whereas blockchains ensure safe, decentralized key distribution. Intelligent Threat Pre-Identification Using RBF Networks: We discover security issues using RBF-based machine learning. These models analyze network traffic and device behavior in real time to identify security concerns such as unauthorized access, data manipulation, and denial-of-service attacks. Early threat detection and mitigation improve network security with this proactive solution. Blockchain technology allows decentralized, immutable key management. The proposed Blockchain-based Trust Security Service Provider (B-TSSP) protects Zigbee edge device cryptographic credentials. Zigbee routers, end devices, and coordinators securely use blockchain ledgers for digital key credentials and authentication. The proposed framework utilizes a blockchain-based trust management mechanism to enhance the dependability of Zigbee-enabled IoT connectivity [25]. These tracts authenticate device identities, implement trust protocols, and record security transactions. The lightweight blockchain architecture ensures secure, undisputed network connections for Zigbee-enabled IoT devices with minimal computing power and energy consumption. This simplified architecture lowers computing costs and ensures security. Latency and energy use via efficient cryptographic methods and consensus processes make the solution scalable for resource-limited IoT applications. For secure communication, Zigbee devices employ end-to-end encryption. Communication is protected by mutual authentication and key agreements. The protocol includes a PUF to secure devices. The Zigbee IP protocol stack allows multi-layer security in the proposed scheme. These layers consist of physical, MAC, adaptation, network, and routing components. Bee-enabled IoT devices’ routing and communication are secure using IEEE 802.15.4 [26,27].

4.1. Consortium Blockchain Network

The permissioned blockchain is built on Ethereum, which is especially well-suited for Internet of Things settings because of its energy efficiency, low latency, and scalability. Fine-grained access control is made possible by this platform, which is essential for protecting communication in Zigbee-enabled Internet of Things networks. We performed the validation of our framework using smart contract testing and platform testing. To discover the vulnerabilities and bugs in smart contract code, we performed validation of smart contracts using the Mocha testing framework. We performed platform testing on personal Ethereum in terms of transaction throughput, block validation time, and validation latency.

Practical Byzantine Fault Tolerance (PBFT) Consensus

The Practical Byzantine Fault Tolerance (PBFT) consensus method for transaction validation is well-suited for permissioned blockchain networks and provides a better trade-off between efficiency and security. In a decentralized IoT Zigbee network, PBFT makes the system resistant to assaults by guaranteeing that it can continue to operate properly even in the event that a certain number of nodes behave badly.

We also explore the blockchain solution’s scalability, emphasizing that it addresses Zigbee-enabled IoT-specific issues including low-bandwidth networks, limited processing resources, and the need for real-time operation. Specifically, the computational burden on Zigbee devices is reduced and IoT activities can be minimally disrupted by shifting most blockchain processing to coordinators or edge devices in Zigbee-enabled IoT networks.

4.2. Physically Unclonable Function (PUF)

We assumed the IoT-enabled Zigbee nodes supported PUF and had trusted storage. The characteristics of the IoT-enabled Zigbee device are based on the manufacturing phase, as every Zigbee device will have unique features [28]. Therefore, the device’s physical characteristics can serve as the basis for generating key pairs. The proposed BCS distributes the key teams and securely communicates among the nodes. Network Key (NK) and Unique Link Key (ULK) are the two types of keys used by the Zigbee alliance, serving many objectives, including joining the network and ensuring nodes can communicate securely [29]. Suppose the ZD with PUF model supports underground storage. This enables keys based on the device’s physical properties to be generated.

4.3. Registration Phase

Before performing any operations, a BCS must enroll all Zigbee coordinators, routers, and end devices. The trusted blockchain will create the signed certificates using a private validator key commonly used as a root of trust. Only the Trusted Permissioned Blockchain can create authentically signed certificates. Any router or edge device that holds the validator’s public key can validate the signed certificate and guarantee the public key’s integrity. Figure 4 shows the node joining procedure in a secure blockchain network. The registration phase is discussed below.

• The ZED enrolls the APUF response in the Cryptographic Key Generation $\left(CKG\right)$ Function. With the help of (the CKG) function, the ZED will reconstruct the key pair (${\left[DP\right]}_{k}ey,{\left[DPr\right]}_{k}ey$).
• The ZED Identifier, called Device ID, is a unique identifier performed by incrementing the global counter of the manufacturer.
• The ZED ID and its Public Key ${\left[DP\right]}_{k}ey$ are sent to the permissioned Blockchain System $\left(pBCS\right)$.
• The $pBCS$ System binds the ZED ID and PUF Public Key and creates the signed certificate using the coordinator/validator private key.
• If the ZED enrollment is successful, then for that ZED, the same above secure procedure will be performed with the coordinator/validator registration process.

The Zigbee IP Coordinator is the full-function device that can initiate a new Zigbee network and maintain the blockchain system. As per Zigbee alliance specifications, there must be a single coordinator for each Zigbee network. The end user will communicate with any ZED only through the Zigbee IP Coordinator. If a current Zigbee network has a new end device that the end user wants to add, then the user must change the network’s status through Blockchain DApps from closed to open state and send the exact request (open state) command to the coordinator. The blockchain system’s smart contract will then confirm the status and modify the system’s state. The coordinator authorizes the broadcast of the join response message, telling all ZD when new joining requests are allowed. This occurs when the Zigbee network transitions to an open state.

On the other hand, no new devices can join the Zigbee network once it closes. Figure 4 shows the secure key exchange and authentication protocol using the APUF and blockchain systems. The process for adding a node to a secure blockchain network is as follows: Each new joiner device must follow the process to connect to a secure blockchain network using a ZR.

• The joiner end device continuously broadcasts at the beginning of the joining procedure by broadcasting an unencrypted beacon request frame and waits for the reply message.
• The coordinator will verify the device ID (EUID, PAN-ID) of the joining device through the blockchain’s smart contract. After the verification of the smart contract, issue the permit join request to the coordinator.
• The coordinator provides the unencrypted beacon acknowledgment for routers to join the Zigbee network. The ZR’s MAC address, personal area network $\left(PAN\right)-ID$, and unencrypted beacon message coordinator public Key (${\left[CPu\right]}_{k}ey$).
• The network declares the joiner end device as connected, but it lacks authentication.
• The joiner end device initiates a connection with the ZR by sending an association request message-1. The ZR requests the device update from the coordinator. Once again, the smart contract will verify the device ID (EUID, PAN-ID) and generate the key pairs using the function Gen-Key $({\left[DPr\right]}_{k}ey$, ${\left[DPu\right]}_{k}ey$) from the blockchain system.
• The smart contract will create the signature:
  $Signed\left(EUID\right|\left|PANID\right|\left|({\left[DPr\right]}_{k}ey,{\left[DPu\right]}_{k}ey)\right|\left|N1\right|\left|{\left[CPu\right]}_{k}ey\right)$ and sends to the ZR. The ZR replies with an Signed association response message to the joining end device.
• The Public Key $\left({\left[CPu\right]}_{k}ey\right)$ of the coordinator will be used by the joiner end device to validate the signature.
• The coordinator’s Public Key ${\left[CPu\right]}_{k}ey$ will be used by the joiner ZED to validate the signature.
• The joiner end device sends a signed association request message-2
  $Signed\left(EUID\right|\left|PANID\right|\left|N1\right|\left|N2\right)$ to the ZR. The ZR requests the Device Update from the coordinator. Once again, the smart contract will verify the Device ID and Nonce N2 from the blockchain system.
• After successfully verifying the signed association request message-2, the smart contract will send the Successful Verification notification to the ZR. The ZR replies with an association response message backing the Permit to Join and Authenticate to the joining end device.

4.4. Authentication and Secure Key Exchange Protocol

A secure communication protocol is required to transfer the data between the ZED and the coordinator via a registered ZR. This safe communication protocol obtains the shared secret key from communication that is both authenticated and encrypted between the coordinator and edge devices in the untrusted field. In this secure communication protocol, we performed mutual authentication with less non-volatile memory (ROM). Before performing the mutual authentication, the blockchain system must enroll the blockchain validator and ZED. This proposed blockchain system solves the problem of less non-volatile memory usage and improves key management. The blockchain validator will access the shared ledger that stores digital key credentials of all the enrolled ZED and ZR, including the Zigbee coordinators. The following key exchange and authentication take place whenever communication is needed between the ZED and the coordinator via a registered ZR in a secure and authenticated manner.

• Once the ZED and ZRs are registered/enrolled in the blockchain system.
• The ZED begins communication with the coordinator via a router by sending a session request message MAC Association Request $\left(AR\right)\left|\right|\gamma$ Where $\gamma \leftarrow {\left[DPr\right]}_{k}eyG$.
• The coordinator begins communication with the ZED via the router by sending a session to rely on the message MAC Association Reply $\left(ARE\right)\left|\right|\xi$ Where $\xi \leftarrow {\left[CPr\right]}_{k}eyG$; G is a Group Generator.
• The ZED sends a Signed certificate MAC Association Request (AR):
  $Signed(ED-ID|\left|PANID\right|\left|({\left[DPr\right]}_{k}ey,{\left[DPu\right]}_{k}ey)\right|\left|N1\right|\left|{\left[CPu\right]}_{k}ey\right|\left|\gamma \right)$
  where $\gamma \leftarrow {\left[DPr\right]}_{k}eyG$ stands for coordinator verification.
• Blockchain’s smart contract will perform the end device verification at the coordinator side using the ZED Key.
• The coordinator sends a signed certificate MAC Association Reply (ARE):
  $Signed(ED-ID|\left|PANID\right|\left|N1\right|\left|N2\right)$ || $\xi$) Where $\xi \leftarrow {\left[CPr\right]}_{k}eyG$; G is a Group Generator for end device verification.
• The ZED will perform the signature verification using the coordinator device Public Key.
• The Shared Key Generation can be calculated between both the coordinator and the ZED to have the necessary secure, shared key.
• ZED secures shared Key: $K\leftarrow {[””\xi DPr]}_{k}ey$ = ${\left[DPr\right]}_{k}eyG{\left[CPr\right]}_{k}ey$
• Coordinator secure, shared Key: $K\leftarrow {\left[\gamma CPr\right]}_{k}ey$ = ${\left[DPr\right]}_{k}eyG{\left[CPr\right]}_{k}ey$
• By encrypting the Zigbee Network Key (NK) ${\left[\left(\psi \right)\right]}_K$ with the shared secret Key and sending it to the ZED, the smart contract of the BCS generates the NK for Zigbee.
• The ZED will decrypt the encrypted Zigbee Network Key (NK) ${\left[\left(\psi \right)\right]}_K$. It uses its shared secret key.

4.5. Key Updating

If ZED wants to update the keys, the APUF response of the ZED will generate the Cryptographic Key Generation (CKG) function. With the help of the CKG function, the ZED will update the key pair ($DP{u}_{k}e{y}^{\prime },DP{r}_{k}e{y}^{\prime }$). The update of the key pairs ($DP{u}_{k}e{y}^{\prime },DP{r}_{k}e{y}^{\prime }$) will be sent to the ZC. The ZC will verify the request through a smart contract, and after proper validations, the same contract sends the updated confirmation back to the ZED. Otherwise, it will discard the transaction (request).

4.6. Threat Model

According to the system model, the Zigbee devices communicate with the coordinators, which act as the validators of the consortium blockchain network. We leveraged Practical Byzantine Fault Tolerance (PBFT) consensus in our framework, as it is a lightweight, faster, and efficient consensus algorithm that is exclusively designed for consortium blockchain networks. The following threats and attacks such as spoofing, DOS and MITM can pre- identify and mitigate the effect. Spoofing can stop by using device registration with blockchain and ECDSA signature verification. A DOS threat can be mitigated with rate-limiting, blockchain sharding, Zigbee token-bucket rate control.

Mathematical Threat Framing

• Input Vector:

  $$\overrightarrow{x}=[\Delta t,RSSI,entropy,hops,key\text{\_}status]$$

  (1)
• RBF Output:

  $$\oint \overrightarrow{x}=\sum _{i=1}^N{w}_{i.\varphi }\left(∥\overrightarrow{x}-\overrightarrow{c}∥\right)$$

  (2)
• Threshold logic:

  $$\oint \overrightarrow{x}<\theta \Rightarrow anomalydetected\left(potentialMITM\right)$$

  (3)

  where $\varphi$ is the radial basis function, ${\overrightarrow{c}}_i$ is the center of neuron i, $w_i$ is the weight of neuron i.

4.7. Pre-Identification Threats on Zigbee Network Using RBF

In this subsection, we present a threat detection on Zigbee network keys which are stored on both PUF and blockchain ledger. We implemented an RBF-based threat detection mechanism to detect attacks on network keys. With Zigbee Light Link profile (ZLL), the devices that communicate over Zigbee possess an AES 128-bit network key that is shared with all devices in the network, even though confidentiality and integrity are ensured through an AES-CCM* block-based protection mechanism using a network key, nonce, and Message Integrity Code (MIC). However, the network keys are prone to spoofing attacks, replying to attacks and flooding attacks [30]. Whenever new Zigbee devices join a network, the IEEE 802.15.4 MAC association procedure is invoked, and Beacon Request frames are issued. The Zigbee router that responds with a Beacon frame issues 16-bit logical ID and a network key ciphered with a pre-installed link key to the Zigbee device. However, whenever an attacker gets access to this network key, the whole Zigbee network becomes compromised. To defend the attacks on Zigbee network keys, we propose an RBF-based threat detection framework. The design and implementation details of the proposed scheme are presented as follows:

• We leveraged the J48 decision tree algorithm to perform threat detection on Zigbee network keys, based on the existing works on RBF-based Intrusion Detection Systems (IDS).
• The training and testing of RBF-based threat detection model is performed using the ZBDS2023 dataset.
• The ZBDS2023 dataset consists of Zigbee traffic and the network key regulated data as multiple PCAP files. These PCAP files are merged into a single PCAP file using Wireshark.
• Using a Python package “pcap handler 0.1.3”, the PCAP file is converted into a CSV file for training and testing the threat detection model.
• The extracted features in the CSV file of the ZBDS2023 dataset using Principle Component Analysis (PCA) are: “version”, “ihl”, “tos”, “len”, “id”, “flags”, “frag”.
• We performed binary classification of attacks on Zigbee security keys; we considered the two labels as “Benign” and “Attacks”.
• Th attacks are detected on Zigbee network keys and the further defense mechanisms can be employed based on the detection results for securing the Zigbee devices in IoT networks and the results presented by the confusion matrix for evaluating threat detection Zigbee Figure 5 and Figure 6.

4.8. Experimental Setup

The proposed work protocol and its attacks have been implemented in the network simulators NS3 and Contiki-Cooja, which have been tested on a network of 10 to 500 nodes that enable the Internet of Things (IoT). The simulation parameters are displayed in Figure 7. The figure shows the results of information processed within the proposed blockchain system. The proposed work’s GUI front-end results, which were evaluated in NS3 and Contiki-Cooja, are shown in the figure. The picture below displays the outcomes of putting the suggested trusted blockchain system into action. The Zigbee coordinator (validator), often serving as a trust anchor, signs the certificates using its private key. Only the Trusted Permissioned Blockchain (via the Zigbee coordinator) can create authentically signed certificates. Any router or Edge device that holds the validator’s public key can validate the signed certificate and guarantee the public key’s integrity. Following the accepted communication structure between the validator and ZN, the ZN will send the ZC (validator) a registration request for key credentials.

In Figure 8, the associated validator receives the registration request from the ZN and validates the transaction request before sending a confirmation response message to the ZN. Figure 9 shows the registration confirmation message between the validator and Zigbee node after both sides verify the process.

Figure 10 demonstrates that the relevant validator will submit a link key request to the Zigbee node, and the validator will then send a key pair to the node after verifying the transaction request. It shows the confirmation message (key pairs) received by the Zigbee node from the validator.

Figure 11 shows the registration confirmation message between the validator and Zigbee node after both sides verify the process. Consider the possibility that the validator chooses not to add the block to the blockchain. The validator will then forward the registration request to the suitable validator (selected randomly using a round-robin approach) so that they may add the block to the BCS. Figure 11 shows the communication message between the group of validators for the creation of the blockchain.

Figure 12 shows that after validation and verification, the validator (leader) produces the block after receiving requests to register new transactions from other validators. Finally, the newly created block is shown in Figure 13 with all new transaction registration requests.

The secure communication between Zigbee devices or Zigbee devices in the application profiles. Any Zigbee node that wishes to communicate with another Zigbee node encrypts their messages using a network key before sending them to the validator. The validator will retrieve information about another node from the BCS. The validator verifies it and sends it to a non-network specific validator. After that, the validator of a different node will check it before sending it to the appropriate node.

Figure 14, Figure 15 and Figure 16 show Zigbee Network setup in the simulator. Communications between Zigbee devices and packets sending and receiving in the formed Zigbee network.

5. Results and Performance Analysis

In this section, we provide the findings and a performance analysis to evaluate the performance of our proposed framework. We evaluate performance metrics such as response time, routing overhead, throughput, transaction delay, authentication, encryption, and decryption. Compared to the existing one, our proposed framework gave a better response time and less delay. Our framework provided the best throughput compared with existing models.

Our permissioned blockchain uses a consensus method optimized for low resources, resulting in a substantially lower computational cost than classic proof-of-work systems. Our method reduces this effect by shifting blockchain-related calculations to edge devices (coordinators), which eases the burden on individual nodes. Edge-Based Processing: Blockchain processes like validation and block building are offloaded to competent edge devices or coordinators, reducing processing strain on individual Zigbee nodes. The blockchain logs only crucial security-related transactions, such as attack notifications and key upgrades. Routine data and logs that are not time sensitive are kept off-chain to reduce transaction traffic and delay.

Optimization Techniques: Batch processing, asynchronous updates, and selectively reporting important security events on-chain minimize disturbance by batching transactions and allowing for background changes.These methods work together to keep Zigbee networks running smoothly and efficiently while maintaining low latency.

Our frameworks offers asynchronous consensus updates, enabling regular network activities to continue uninterrupted while the blockchain is synchronized. This architecture strikes a compromise between security assurance and the real-time operating requirements of Zigbee networks.

RBF is suitable for nonlinear data. Zigbee-enabled IoT network device and traffic are diverse and dynamic, and data often show nonlinear patterns. It accurately simulates nonlinear decision boundaries. RBF networks are often less computationally demanding and need less training time, which makes them suitable for real-time or resource-constrained IoT applications. RBF effectively and efficiently understands and comprehends selected models because it strikes more of a balance between speed, performance, and interpretability than other ML models. SVMs become computationally costly when dealing with huge datasets, particularly when they include a lot of features and adjusting the kernel settings might be delicate and complicated. The Random Forest model performs well on structured data, but in our scenario, it was less able to generalize to unknown anomaly detection. CNNs are not the greatest match for tabular or temporal data, which is often seen in IoT traffic logs, even though they work well for image-based or geographical data. They need large, labeled datasets and significantly more computing resources. It does not fit for Zigbee devices which are low-power devices.

The request and response time between the Zigbee creation and adding the block to pBCT network takes 57.44 ms. The key generation from the pBCT network takes the average response time as depicted in Figure 17. The request and response time for adding a block to the PBFT network from Zigbee creation is measured at 57.44 ms. Key generation from the PBFT network exhibits an average response time, with a maximum of 12.46 ms for key pair generation. Additionally, signature creation and verification times for Zigbee coordinators are 32.45 ms and 30.3 ms, respectively, indicating the computational efficiency of the proposed system, see Figure 18. For generating the key pair, the maximum response time is 12.46 ms. The creation of the signature takes 28.18 ms and the verification of the signature takes 26.9 ms by the Zigbee coordinators. For the Zigbee coordinators, the creation of the signature takes 32.45 ms and the verification of the signature takes 30.3 ms. The edge device needs to be validated properly by the Zigbee coordinators. An average end-to-end delay of the routing protocols is depicted in Figure 19. The average throughput of the AODV, RPL, and RPL-AODV protocols is depicted in Figure 20.

5.1. Security Analysis

In this section, we presented the security analysis of the proposed framework. We evaluate our framework against DoS and MITM attacks on IoT-enabled Zigbee networks. We employ cryptographic notations and mathematical modelling.

DOS Attack: This attack may put a victim device on an unending retransmission cycle. The blockchain validators eliminate the single point of failure and prevent DoS attacks. The Zigbee Network Key Sniffing Attack exploits a vulnerability in the key transportation issue of the Zigbee network, all while maintaining the minimum security level. The sniffing attack is prevented by the blockchain, as all the packet data are encrypted.

Man in the Middle Attacks: The communication between the two parties creates a separate link between them in our model and is signed using ECDSA; the attacker requires access to one of the parties’ private keys to steal or alter the messages. Creating a fake private key is computationally impossible and as complex as solving the ECDLP. Because of this, our suggested model is resistant to Man in the Middle Attacks.

Mathematical Security Analysis

A mathematically grounded security analysis of a Zigbee-based IoT network focuses on DoS and MITM attacks vectors and how cryptographic and threat detection mechanisms are working with the combination of blockchain and RBF to provide security guarantees. The following subsections describe the steps of mathematical modeling.

• System Model:
  • Let $D=\{d_1,d_2,\dots ,d_n\}$ be the set of Zigbee devices.
  • Each device $d_i$ is connected via the Zigbee protocol to a coordinator.
  • Communication between nodes is encrypted using AES-CCM and authenticated via ECC (Elliptic Curve Cryptography.)
• AES-CCM Encryption:
  Data $m\in {\{0,1\}}^l$ are encrypted as:

  $$c={\mathrm{AES}\text{-}\mathrm{CCM}}_k(m,\mathrm{nonce})$$

  (4)

  where: K is a 128-bit secret key and nonce is unique for each session.
• ECC-Based Authentication:
  Each device has:
  • Public–private key pair $(P_i,S_i)$.
  • Digital signature using ECDSA:

    $$\mathrm{sig}={\mathrm{ECDSA}}_{S_i}\left(H\left(m\right)\right)$$

    (5)

    where H(m) is a secure hash of message m
    Receiver verifies:

    $${\mathrm{Verify}}_{P_i}(m,\mathrm{sig})=\mathrm{True}$$

    (6)
    ECDLP (Elliptic Curve Discrete Logarithm Problem) assumption:
  • Given P = kG, it is infeasible to find k. This provides resistance to MITM.
• RBF-Based Intrusion Detection
  Let:

  $$\overrightarrow{x}=[x_1,x_2,\dots ,x_d]\in {\mathbb{R}}^d$$

  (7)

  be the feature vector for a communication session (e.g., timing, hop count, entropy, RSSI).
  The RBF output:

  $$f(\overrightarrow{x})=\sum _{i=1}^N{w}_i·\varphi \left(\right||\overrightarrow{x}-{\overrightarrow{c}}_i\left|\right|)\mathrm{where}\varphi \left(r\right)=e^{-\gamma r^2}$$

  (8)
  If:

  $$f(\overrightarrow{x})<\theta \Rightarrow \mathrm{Anomaly}\mathrm{Detected}$$

  (9)

  trained on normal traffic, the RBF network can detect attacks such as MITM, DoS.
• Blockchain-Based Security Logic
  • Let $T=\{t_1,t_2,\dots ,t_m\}$ be a sequence of transactions (registrations, data logs)
  • Each transaction is:

    $$t_i=H(d_i\parallel \mathrm{timestamp}\parallel \mathrm{signature})$$

    (10)
  • Block $B_j=\{t_i,\dots ,t_k\}$, linked by:

    $$\mathrm{Hash}\left(B_{j-1}\right)\Rightarrow \mathrm{immutability}$$

    (11)
  Our framework provides the auditability, for which all Zigbee devices’ actions are recorded, with decentralization, and for which there is no single point of failure and resistance to sniffing via encrypted logs.

6. Conclusions

The smart hybrid security framework uses blockchain and Radial Basis Function (RBF) networks to protect IoT networks that are enabled by Zigbee. We used a blockchain-trusted security service provider to generate secure application keys, network access, IoT device authentication, and key management and RBF-based anomaly detection handle threat pre-identification. The proposed framework provides security and resilience solutions that cover unauthorized access, network-wide key updates, and insecure key distribution and a pre-threat identification framework with a ZBDS2023 dataset. Our investigations indicate that the framework’s increased security and computational speed make it suitable for a resource-limited Zigbee-enabled IoT environment. The findings show that the hybrid technique can protect smart networks against cyberattacks, pre-threat identification, and scale. Future research will optimize blockchain-trusted security service provider mechanisms of our framework to accommodate more IoT technologies and protocols and increase the quantum-resistant cryptography methods to secure next-generation IoT networks with real-world testbed smart healthcare hospital networks.