A Scalable Security Approach in IoT Networks: Smart Contracts and Anomaly-Based IDS for Gateways Using Hardware Accelerators

With the widespread integration of new technologies, IoT devices are becoming increasingly diverse and capable of handling highly complex tasks, compared to previous generations. This evolution has led to demands for a comprehensive security approach across multiple layers of an IoT architecture. This work proposes a scalable security solution from the edge to the cloud, combining Blockchain technology and anomaly-based Intrusion Detection Systems (IDSs). Smart contracts provide a transparent environment for registering and managing IoT devices on the cloud. Specifically, the smart contract includes two authorization levels for managing administrators and IoT devices. Besides, anomaly-based IDSs are deployed at Gateways to detect network attacks. We propose using lightweight machine learning models on FPGA hardware acceleration for Gateways. We have simulated the Blockchain network on the Ganache software, demonstrating that the smart contract effectively manages administrators and devices such that only authorized entities can access the system. The FPGA-based Gateway, which contains pre-trained Artificial Neural Network (ANN) and Convolutional Neural Network (CNN) detection models from the IoT-23 dataset, has been deployed on the Alveo U280 card. The ANN model has achieved the highest processing speed at 20Gbps. The results indicate that integrating Blockchain and anomaly-based IDS significantly enhances scalable security in IoT networks.

SECTION I. Introduction

Internet of Things (IoTs) security has become increasingly important in the 2020s due to its remarkable technological evolution. Firstly, there are ever-increasing demands for automation and smart devices in essential sectors, including healthcare, military, manufacturing and smart homes/cities, to name a few. This leads to an estimation of billions of new IoT devices joining each year [1]. Secondly, Artificial Intelligence (AI) technology is having a significant impact on human life. For example, a machine can imitate human behaviors by learning from experiences and then being able to deal with complicated tasks very rapidly. Besides, hackers can use AI to explore a system’s vulnerabilities or attack the system to disrupt the system’s operations. This research examines AI and Machine Learning (ML) to enhance security in IoT networks.

In 2024, the financial market witnessed a new wave with the spot Exchange-Traded Fund (ETF) approvals [2] of the two most popular cryptocurrencies, Bitcoin and Ethereum. These approvals have made cryptocurrencies becoming more valuable and accessible than before. Blockchain, the underlying technology behind cryptocurrencies, has gained significant adoption with numerous emerging applications. Specifically, Blockchain is a form of Distributed Ledger Technology (DLT) that operates a decentralized, peer-to-peer network to maintain synchronized copies of the ledger. This distributed data storage ensures data integrity, redundancy and security by eliminating the single point of failure in the centralized storage systems. Smart contracts were introduced in modern Blockchain networks, which have the ability to integrate business logic into the Blockchain. Smart contracts are triggered by transactions and execute automatically without a central entity. This work utilizes smart contracts to manage access control in IoT networks.

Besides security on the cloud, the IoT network can deploy security approaches to detect attacks early at the edge (device level). These approaches can be categorized into signature-based and anomaly-based IDS. A signature-based IDS can only detect known attacks by comparing input patterns with the database. To tackle this issue, state-of-the-art IDSs use anomaly-based approaches [3] to detect unknown attacks. This work focuses on an anomaly-based IDS at the edge. This approach brings security functions to the device, thus increasing the possibility of preventing attacks before they cause global damage to the system. In particular, lightweight ML models are trained and implemented on IoT Gateways to detect network attacks.

Hardware accelerators such as Graphic Processing Units (GPUs) and Field Programmable Gate Arrays (FPGAs) have a vital role in cybersecurity. For instance, with the rapid growth of databases in a system, an anomaly-based IDS demands up-to-date ML models to deal with attacks; GPUs have been proven as a time-efficient platform for training ML models compared to traditional CPUs (Central Processing Unit). While GPUs excel in general-purpose parallel computations, FPGAs adapt better to a specific task, such as inference, with less energy consumption. In terms of IoT devices, security solutions vary according to different perspectives. Edge devices are limited in computing resources and are susceptible to malware, side-channel and authentication attacks. There are more powerful devices, called Gateways, which are usually located between edge devices and the cloud, to collect data and manage edge devices. Gateways face higher-level attacks such as network, data and privacy attacks. This work accelerates lightweight ML models, including ANN and CNN, on an FPGA-based architecture.

A. Our Contributions

We propose a network architecture for IoT networks comprising three layers, namely cloud, control and IoT devices. The proposed architecture enhances system security and scalability by leveraging smart contracts technology and ML on hardware accelerators. Secured functions are designed and integrated into each layer.

We design and implement smart contracts on the cloud layer to manage access control and verify IoT devices. IoT management data is stored on smart contracts in a decentralized network, in which device authentication is executed automatically and recorded on the Blockchain. We propose an FPGA-based architecture for Gateways, which integrates lightweight ML models to detect attacks at the device level. Furthermore, the feature extraction modules are implemented on FPGA to reduce overhead relative to CPU and GPU schemes.

Finally, we evaluated the proposed system using various testing scenarios. Smart contracts are deployed on a simulated Ethereum Blockchain network. A setup is built to simulate the smart contract connections and operations. The Gateway is implemented and tested on a NetFPGA-PLUS platform (Alveo U280 card [4]), which is a code base built for the Xilinx Alveo Data Center Accelerator Card based upon Xilinx Virtex Ultrascale+ FPGAs. The system is evaluated on the IoT-23 dataset [5]. Hardware resource usage and power consumption are also discussed.

B. Organization

The rest of this paper is organized as follows. Section II introduces background knowledge related to our research, including DLT technology and our previous works in anomaly detection. Related work will also be discussed in detail in this Section. In Section III, we present the proposed architecture, from a high-level view of the system to the implemented prototype. We explain the experimental setup and evaluate our implementation in Section IV. Next, we discuss the strengths and weaknesses of the implemented system in Section V. Finally, the conclusions and future work are presented in Section VI.

SECTION II. Preliminaries

A. Distributed Ledger Technology

DLT [6] operates based on a digital ledger system with programmed protocols that allow reading, writing and updating the distributed ledger. The idea behind DLT is to maintain identical copies of data in a network of nodes. The nodes communicate with each other through the peer-to-peer principle, where each node maintains the up-to-date version of the ledger. This mechanism provides transparency, resilience and security, as there is no single point of failure compared to traditional centralized systems. Thanks to these advantages, DLT has become increasingly popular with broad applications across various sectors. The fundamental technologies behind DLT involve cryptographic techniques, such as hash functions, digital signatures and public key cryptography. Besides, this is the technology behind Blockchain, Directed Acyclic Graphs (DAGs), hashgraphs, corda, bigchainDB, etc.

Blockchain [7] is the most successful technology under DLT due to the ongoing adoption of Bitcoin, the oldest cryptocurrency. Blockchain forms a chain of blocks, where the current block is built based on the previous block’s header hash value and the combination of transactions, a timestamp, a nonce and a Merkle root to include a hash of all transactions. Blockchain inherits core characteristics from DLT, such as data integrity, immutability and redundancy. Blockchain can be recognized based on the permission model and consensus mechanism used. There are three Blockchain types according to permission models, as follows:

• Public Blockchains (Permissionless) are distributed computer networks open to the public. Any nodes that satisfy certain requirements in computing resources and network bandwidth can join the system. Clients can request or validate transactions publicly on the Blockchain. A public blockchain is fully decentralized, as there is no central or third-party authority involved.

• Private Blockchains (Permissioned) are not open to the public since they have access restrictions. Clients need to acquire permissions before interacting with the Blockchain. A private blockchain is dedicated to a specific group of users or an organization; in other words, it is centralized to some extent.

• Hybrid and Consortium Blockchains combine the features of both private and public blockchains. While a hybrid blockchain is usually controlled by one authority, a consortium blockchain is controlled by a group of organizations rather than a centralized entity.

A consensus mechanism is used in a Blockchain network to achieve agreement between nodes (validators) before adding a new block to the Blockchain. It can be used as a criterion to distinguish between Blockchains. Here, we discuss the two most popular consensus mechanisms, which are Proof of Work (PoW) and Proof of Stake (PoS).

• PoW consensus was originally used in the Bitcoin and Ethereum Blockchains. Nodes in the PoW network try to solve a cryptographic puzzle, which presents the new block to be added to the Blockchain. The main concept in PoW is that the puzzle is difficult to solve but easy to verify; when a node finds a possible result, it broadcasts to the network and the block is added when more than 50% of nodes agree with the result. Blockchains using PoW are secured since the attackers need to control more than 50% of the votes to add a malicious block.

• PoS consensus was proposed to reduce the computational resources in PoW. Generally, in a PoS network, each node has to lock up the native asset (cryptocurrency) to join the consensus protocol, in which the higher the number of asset units staked, the higher the probability the node will be chosen to add the next block.

Besides, there are other consensus mechanisms, such as delegated PoS, Proof of Authority (PoA), practical byzantine fault tolerance, proof of elapsed time, etc. Each consensus has different advantages; thus, it can be selected for a Blockchain depending on design choices.

Smart contract [8] was first introduced in the 1990s. The smart contract carries the concept of self-executing logic without intermediaries to achieve automation and help reduce enforcement costs. In 2015, Ethereum was launched as the first Blockchain to support complex smart contracts. In the Ethereum Blockchain, smart contracts are self-executing byte codes containing defined logic used to do a specific task. Most importantly, all the changes are recorded on the Blockchain. Thus, historical records remain transparent and immutable. Figure 1 illustrates the contract deployment and users’ interaction flows on a public Blockchain network.

FIGURE 1.

The smart contract development and interaction process flow.

The contract deployment starts with a developer implementing the smart contract using a high-level language, such as Solidity [9]. The contract is tested and compiled to generate byte code. Next, the contract deployer can deploy the smart contract using this byte code by initiating a contract creation transaction and sending it to the Blockchain network, where miner nodes insert the transaction into a new block and add it to the Blockchain. Clients can interact with the contract using the deployed contract address with the associated method and input data.

This work explores the Ethereum Virtual Machine (EVM), an engine of the Ethereum Blockchain. EVM serves as a runtime environment for executing smart contracts on Ethereum. The Ganache [10] software was for simulating the EVM environment and also for testing smart contracts. Ganache allows developers to deploy smart contracts in a simulated Blockchain, which reduces cost compared to the live Ethereum blockchain.

B. Anomaly-Based IDS

The anomaly-based IDS is adapted from our previous work in [11]. The implemented system uses lightweight ML models to detect network attacks based on a packet’s header, including IP addresses, TCP/IP ports and protocol. Figure 2 illustrates the system’s processing flow on the IoT-23 dataset [5].

FIGURE 2.

The platform-dependence anomaly-based IDS framework on the IoT-23 dataset.

The proposed anomaly-based IDS is platform-dependent and comprises three stages, namely Data preprocessing, Training & validation and Inference engines. Here, we describe the dataset and framework processing flow in details.

1) Dataset

The IoT-23 dataset [5] contains network packets captured in an IoT network from 2018 to 2019 and was published as part of the Avast AIC laboratory in 2020. This dataset involves labeled data and raw network packets. The labeled data are generated using the signature-based approach in which the known patterns are used to label the network flows. Table 1 shows the record distribution containing 325,307,990 labeled records in the dataset.

TABLE 1 The IoT-23 dataset record distribution

2) Data Pre-Processing

The Data Pre-processing stage prepares input features for the next stage on the Central Processing Units (CPUs). The feature extraction process is different for ANN and CNN models. While the ANN model uses packet header fields as input, the CNN model requires a converting process in which network packets are converted to fixed-size images.

3) Training and Validation

The training and validation processes are conducted on the GPU platform. The ANN and CNN models are tested using different configurations to produce lightweight models with high detection rates. In particular, the ANN model is configured with 32 neurons in the hidden layer, each followed by a Rectified Linear Unit (ReLU) activation function. The CNN model architecture includes four convolutional layers, two max pooling and two-platen layers at the end [11].

4) Inference Engines

The inference stage will be evaluated with three engines using different hardware accelerator combinations. Each engine has a Feature Extraction (FE) and a Packet-to-image (P2I) module as data pre-processing for the ANN and CNN models, respectively. The engines can be described as follows:

• Engine 1 only uses CPUs without any other hardware accelerator.

• Engine 2 uses a GPU for running the models while the data pre-processing tasks are assigned to CPUs.

• Engine 3 implemented on an FPGA-based architecture.

The processing performance of these engines will be discussed in section IV-C3.

C. Related Work

With continuous and rapid developments in IoT architecture and technology, IoT security can be developed at four different layers [12]: application, processing, network, or perception layers to counter threats and vulnerabilities. Each layer faces different challenges due to the variety of security threats [13]. For instance, since edge and sensor devices at the perception layer are limited in computing resources, they require lightweight protection models rather than complex algorithms [14]. The network presents the communication channel between devices and administrators; thus, this layer attracts most attacks, such as Denial-of-Service/Distributed Denial-of-Service (DoS/DDoS), routing, traffic analysis, spoofing attacks, etc. In the processing and application layer, there are issues related to access control and data processing privacy that need to be resolved. The traditional method with static access control is becoming inefficient in modern systems [15]. This paper proposes a flexible access control solution using Blockchain.

Blockchain and smart contracts have had an enormous impact on IoT security lately. It has been involved in artificial intelligence of things [16] as a solution in terms of efficiency, security, privacy, trust and incentives. The authors in [17] have proposed Blockchain-enhancing federated learning in a cluster-based architecture for anomaly detection in IIoT networks. According to researchers in [18] and [19], Blockchain and smart contracts technology enhances IoT security in different aspects, including authentication, access control, privacy, trust, and reputation. Blockchain and smart contracts are widely used in IoT access control and security due to its decentralized nature and data integrity. Table 2 summarizes existing research results on IoT security using Blockchain.

TABLE 2 Summary of existing literature on IoT security and access control using Blockchain and smart contracts

In [23], the authors proposed Blockchain for two-factor authentication. The authentication is deployed at the application level, and there are no countermeasures if the devices are infected. The authors in [20], [22], [27], and [29] have focused on high-level IoT access control using smart contracts. The designs are purely based on smart contracts on the Blockchain. The research [27] has combined smart contracts in blockchain with attribute-based access control. However, the work only focuses on access control under the edge Internet of Things and does not deal with the existing environment.

Similarly, Blockchain has been used as an intermediate mechanism for consumers to interact with IoT networks [28]. The gateways, which control edge devices, can interact with smart contracts. In [24] and [26], the authors have proposed off-chain solutions for data storage since it is expensive to store data on a live Blockchain (or on-chain). In particular, the authors in [26] have used a private Blockchain with PoA consensus to deploy security from the sensor nodes’ level. However, the work did not test the system’s scalability. In [21] and [25], the authors have combined smart contracts and IDSs for IoT security and access control. This concept has added an extra layer of security to IoT networks. In addition, security in a smart contract is also a concern [25] and requires careful attention to build a comprehensive secured system. While much research focuses on designing smart contracts, IDS and hardware accelerators can potentially add efficiency and scalable security to IoT networks.

Next, we study the literature on anomaly-based IDSs using the IoT-23 dataset, summarized in Table 3.

TABLE 3 The literature on anomaly-based IDS using the IoT-23 dataset

The authors in [30] have reported that LSTM achieved better accuracy compared to the GRU model. The results also show that data pre-processing has had a great effect on how well the system can detect attacks. For instance, the researchers in [31] have converted data into time series format before applying a stack of three 1D-CNN models with different settings to achieve 99.9% accuracy. The authors in [32] have used a feature selection module to get the most impactful feature set. Besides, SMOTE (Synthetic Minority Oversampling TEchnique) has been proposed in [35] to solve the imbalance issues in the IoT23 dataset and improve the accuracy. Hybrid CNN-LSTM models have been used in [36] and [37] to achieve 95.0% and 99.2%, respectively, in accuracy. The authors in [38] have designed a workflow that includes feature extraction & calculation, feature selection, training and testing to reach 99.8% accuracy. On the one hand, most of the mentioned works are software-based, and the research objective is to optimize the accuracy metric. On the other hand, they have not been tested using raw packets to evaluate the proposed ML models in terms of processing throughput. Our approach is not only to accelerate detection models using hardware-based platforms but also to be able to process raw packets at high speed.

Finally, AI-based security on hardware accelerators, especially GPU and FPGA platforms, are considered in this Section. FPGAs have advantages in parallel processing and reprogrammable capabilities, making them faster and more efficient in executing heavyweight processes, such as image processing, than microcontrollers [39]. Lightweight ANN models have been trained on the NSL-KDD dataset and deployed on a System-on-a-Chip (SoC) FPGA platform [40]. They have reported a speedup of 161.7 times faster than software-based methods. Similarly, [41] has proposed a framework integrating power side-channel capturing and ML models for detecting attacks on a Xilinx ZCU104 FPGA. Specifically, the framework involves data collection and pre-processing, followed by training neural network models using a GPU. The trained model is then quantized and passed through the High-Level Synthesis (HLS) tool to generate a Register Transfer Level (RTL) design, which is deployed onto the FPGA for inference with overhead at the picosecond level.

DDoS attack mitigation for IoT devices using a SoC platform has been investigated in [42]. This work has implemented a method for defending against DDoS attacks on a ZedBoard [43]. In this system, the FPGA assists the ARM CPUs in mitigating DDoS attacks. Experimental results have demonstrated that the system can handle up to 10,000 requests per second before the CPU becomes saturated. This rate is approximately 4.58 Mbps in processing throughput. In [44], the researchers have proposed a design that combines an FPGA and CPU to reduce threat traffic. The FPGA is designed in a pipelining fashion for user instruction analysis. They have reported a maximum forwarding processing capacity of 1.652 gigabits per second.

Overall, security approaches for IoT networks utilizing Blockchain and smart contracts are gradually becoming a growing topic of research interest. In addition, continuous advancements and improvements in AI drive innovation in anomaly-based IDSs. However, the number of studies that combine the two approaches to enhance scalable security remains limited. In this paper, we propose a scalable security approach that combines Blockchain and anomaly-based IDS using hardware accelerators for IoT networks. The implemented system has demonstrated the comprehensive protection approach from the edge to the cloud in an IoT architecture.

SECTION III. Proposed Architecture

In this section, we introduce an overview of the proposed architecture and describe the system implementation in detail.

A. Overview

Figure 3 illustrates the proposed architectural overview with three layers, which are Cloud, Control and IoT Devices.

FIGURE 3.

The proposed architecture with three layers: IoT Devices, Control and Cloud.

The Cloud layer presents the top level in the proposed architecture in which the Blockchain Nodes constitute a Blockchain network. The Blockchain network represents a distributed digital ledger that supports smart contract technology. We propose smart contracts for managing access controls and security in the IoT networks.

The Control layer is the intermediate layer to either interact with the Blockchain network or manage IoT devices through Northbound APIs and Southbound APIs, respectively. This layer comprises different administrators who have different roles in the system. A Web3 Application module indicates that the administrator can interact with the Blockchain using Web3 technology. As shown in Figure 3, administrators are presented as blocks and can be described as follows

• The Contract Owner block is the administrator with the highest authority level to deploy smart contracts onto the Blockchain network and so has full control over the deployed smart contracts. The contract owner owns a local Admin Database to manage administrators through the Web3 Application module.

• The Web3 Admin blocks focus on organizing IoT gateways and edge devices.

• The Security Admin blocks are administrators who are equipped with hardware accelerators for training and validating attack detection models.

The IoT Devices layer represents an IoT network where IoT devices are organized in groups. Each group is proposed to have one FPGA-based gateway device to gather data from the edge devices. The gateway sends the collected data to administrators at the Control layer through the communicating channel, called Southbound APIs.

B. Implementation

Here, we describe the protocols and technologies used to implement the proposed architecture. This involves the Blockchain and smart contract in the Cloud layer, the Web3 application modules in the Control layer and the FPGA-based Gateways in the IoT Devices layer.

1) Blockchain and Smart Contract

The implemented system utilises a public Blockchain using the Ganache development tool; this Blockchain supports the EVM environment for smart contracts testing and development. The main smart contract is designed with basic management functions to store information about administrators and devices in the network. Figure 4 illustrates the simplified UML class diagram of the main smart contract. In this implemented version, we propose two modifiers corresponding to two levels of authentication on the smart contract:

• The onlyOwner modifier is a filter to allow the contract owner, who has the highest priority on the deployed smart contract, to access certain functions on the smart contract. This owner’s address is assigned at the initial stage and can be updated by the owner. Other administrators must be approved by the contract owner before joining the network.

• The onlyAdmin modifier represents approved administrators’ access. These administrators can interact with the smart contract to manage IoT devices in the network.

FIGURE 4.

The simplified UML class diagram of the main smart contract.

2) Web3 Applications

The Web3 Application module is the compulsory module used by each administrator to communicate with the smart contracts on the Blockchain. We describe Web3 Application modules corresponding to the three administrator groups in the Control layer as follows

• The Contract Owner has a local database to store the administrators’ information in the network. Administrators must first send their EVM address to the contract owner, who then decides whether to approve this address as a legitimate administrator in the smart contract. Figure 5 depicts the sequence diagram for adding a new administrator process.

  Initially, the new administrator sends its own EVM address to the contract owner. Then, the contract owner works with the local database before getting the latest information about the received address on the Blockchain. If the address has not been added, the contract owner can send a transaction to add the new administrator and update the local database afterward. The new administrator can verify the result by reading the smart contract.

• The Web3 Admin also has a device database, which manages the statuses and EVM addresses of the new IoT devices. Figure 6 illustrates the sequences from registering to security validating when adding a new device to the network.

  An approved administrator first registers the new device with an EVM address with the smart contract. The smart contract then waits for the security monitoring process, which updates the device status by an approved security admin. This process includes two main steps: Step 1 is registering the device in the queue, and Step 2 is waiting for verification by the security module.

• The Security Admin is proposed with an anomaly-based IDS module, which is adapted from our previous work [11]. These administrators are responsible for training and validating lightweight attack detection models. The pre-trained model will be accelerated on FPGA hardware. Besides, a Web3 application module is used to update the smart contract if there are alerts from Gateways about monitoring devices.

FIGURE 5.

The sequence diagram of adding a new administrator (denoted as A) process.

FIGURE 6.

The sequences of adding a new device (denoted as D) to the network.

3) Gateways

This work proposes high-speed FPGA hardware as a platform for Gateways to detect network attacks. In this implementation, we propose the FPGA-based architecture, which is wrapped in the NetFPGA-PLUS platform [45]. The NetFPGA-PLUS platform includes Xilinx Alveo Data Center Accelerator Cards based upon Xilinx Virtex Ultrascale+ FPGAs. The platform code base operates on the U200, U250 and U280 cards. Figure 7 depicts the NetFPGA-PLUS Gateway architecture that can be described as follows

• The PCIe interface block represents the communication between a host machine and the NetFPGA-PLUS card through a Peripheral Component Interconnect Express (PCIe) interface; this block simulates virtual network interfaces, which are controlled by the host machine. These virtual interfaces are named DMA_In and DMA_Out, presenting the input/output interfaces to/from the NetFPGA-PLUS card, respectively.

• The NIC blocks, including NIC0 and NIC1, are physical network interfaces on the NetFPGA-PLUS card.

• The Input Arbiter block operates based on a queue mechanism that uses the round-robin algorithm to select incoming packets from different input interfaces. In other words, this module merges network packets from multiple input sources, including virtual and physical interfaces, to create an output stream of packets.

• The Packet Processor block has scanner modules, which accommodate pre-trained lightweight neural network models. This block will be discussed in detail in the next Section.

• The Output Queues block operates inversely to the Input Arbiter block described above; this block receives the processed packet stream and distributes it to the corresponding output interfaces.

FIGURE 7.

The block diagram of the NetFPGA-PLUS Gateway with security integration.

4) Packet Processor

As shown in Figure 7, the Packet Processor block is implemented in the NetFPGA-PLUS Gateway between the Input Arbiter and Output Queues block. This block either forwards network packets or detects network attacks using neural network models. The network packets are processed as follows.

• The Distributor module receives the network packets from the Input Arbiter block; it then distributes the data simultaneously to three different modules, which are FE, P2I Processor and RAW packet FIFO.

• The ANN processing contains FE, ANN Scanner, ANN Result Packaging and Packet FIFO modules. Initially, network packets are passed through the FE module to extract header fields (source and destination IP addresses, ports and protocol). These extracted data serve as the input for the ANN Scanner module. The scanned results are packaged with the extracted header fields and stored in a Packet FIFO.

• CNN processing has a similar structure to the ANN processing. However, instead of only examining header fields, the CNN model processes the entire network packet, including header and payload. Figure 8 illustrates the P2I processor module, which converts network packets into images.

  The module is implemented on the FPGA-based architecture using three state machines, namely Packet Buffering, Read and Shift and Read Image, to transform network packets in different lengths into fixed-size images. The Packet Buffering state machine receives network packets and stores them in a Packet FIFO. Given that a network packet length is not fixed, this state machine standardizes all network packets to a fixed length (1500 bytes) using the zero padding method. Next, the Read and Shift state machine uses a shift register to read the packet frames from the Packet FIFO and write this data as image rows to the IMAGE FIFO. Finally, the Read Image state machine reads the image data from the IMAGE FIFO and sends it to the CNN Scanner module. The scanned results are packaged with the packet header and stored in a Packet FIFO.

• The Packet Selector module merges packets from different sources, including original network packets and alarm packets from the ANN processing and CNN processing. The output is a network packet stream routed to the Output Queues block. Figure 9 is the flow chart illustrating the packet’s priority processing order. Integrating additional security functions is considered to add overhead to the system. Therefore, forwarding raw packets has the highest priority in this implemented version, followed by the result packets from the ANN and CNN scanners.

FIGURE 8.

The P2I processor module state machines and data flow.

FIGURE 9.

The Packet Selector module’s flow chart expressing packet priority order.

SECTION IV. Experiments

In this section, we evaluate the implemented system by layers. Firstly, we introduce the experimental setup, simulating the system in a practical environment. Next, we perform standalone experiments on the FPGA-based Gateway. Finally, the smart contract on the cloud and the full system are tested.

A. Setup

Figure 10 depicts the setup for testing the implemented system. The setup includes four main host machines, which are described below.

• The Blockchain Server runs on the Dell Precision 7920 Tower with 512GB of memory and Intel(R) Xeon(R) Platinum 8276 CPU @ 2.2GHz x 112 on Ubuntu 22.04.2 LTS operating system. The server has Ganache blockchain configured with version 2.7.1. The hostname, port number and network ID are 127.0.0.1, 7545 and 5777, respectively. In addition, the host machine is equipped with dual NVIDIA Quadro GV100 GPUs.

• The SSH Gateway (Intel(R) Core(TM) i7 - 10700, 2.90GHz, 32GB of RAM on Rocky Linux 8.10) acts as the access gateway for devices on the internet to the Blockchain server.

• The Security Admin contains an Ethernet (Intel E810-CAM2) and a NetFPGA-PLUS card (Alveo U280); each has two QSFP28 transceivers. The Ethernet card is directly connected to the NetFPGA-PLUS card using QSFP28 cables for monitoring network packets at high speed. The NetFPGA-PLUS card is programmed as an IoT Gateway and is integrated into the host machine through a PCIe interface. The administrator can interact with the Blockchain server through a local area network or an SSH Gateway.

• The Simulator (Intel(R) Core(TM) i7 - 9750H, 2.8GHz x 6 cores, and 16GB of RAM on Windows 10 Pro) demonstrates the contract creator and Web3 administrators using Jupiter Notebooks under the Anaconda toolbox.

FIGURE 10.

The setup with the full system in the real physical network.

In this setup, the Blockchain Server simulates the cloud layer that runs the Blockchain and smart contracts. This host machine also has GPUs for training, verification and inference of ML models. The SSH Gateway works as a tunnel, providing access to the Blockchain so that the Simulator, which has a private IP address, can interact with the deployed smart contracts on the Blockchain Server.

B. FPGA-Based Gateway

1) Implemented Result

The FPGA-based Gateway is developed using Verilog on Vivado version 2018.2. The implemented design is deployed on a Xilinx ALVEO U280 card, which includes UltraScale+ XCU280-L2FSVH2892E device (containing a total of 1,303,680 LUTs, 600,960 LUTRAM (LUTR), 2,607,360 FFs, 2,016 BRAMs and 9,024 DSP slices). Table 4 shows the implemented blocks’ hardware resource usage, timing and power consumption estimation.

TABLE 4 The implemented results of FPGA hardware on Vivado 2018.2

The Gateway consumed 11.97% LUTs, 8.78% FF and 14.61% BRAM of the ALVEO U280 card. The Packet Processor block used 40,391 LUTs, which contributed approximately 25.9% to the Gateway resource usage. Besides, this block required 898 DSP slices, which contributed to 9.95% DSP available on the card, for ANN and CNN calculations. The maximum frequency is approximately 309.8MHz, and the total power is reported as 20.08W.

2) Performance

In this test, we measure the processing throughput of the FPGA-based Gateway at high speeds on two criteria: processing speed and packet loss rate. This is a standalone test on the Security Admin host machine, utilizing the Ethernet Card to replay network packets directly to the Gateway using QSFP28 transceivers. We divided network packets into six groups based on the packet length (ranging from 64B to 1500B). For each group, we gradually increase the transmission rate (ten trials each) by using TCPreplay processes [46]. Figure 11 depicts the test results through six bar charts.

FIGURE 11.

The performance test results of different packet size (64B-1500B).

For packets with a length of 64B, we gradually increased the packet transmission rate from 0.20Gbps to 1.41Gbps. Before packet loss occurred, the maximum throughput recorded for forwarding raw packets and the ANN scanner were 1.12Gbps and 1.02Gbps, respectively. At the 10th trial, packets are replayed at 1.41Gbps; the packet loss rates in the two cases were 16.8% and 20.5%, respectively. With greater packet lengths, such as 128B, 256B, 512B, and 1024B, the Gateway achieved higher throughput rates before packet loss. In detail, the throughput is recorded at 2.1Gbps, 4.2Gbps, 8.3Gbps, and 14.0Gbps, respectively. The 1500B packets produced the most stable results, maintaining an incoming speed of 20.0Gbps for forwarding raw packets and 0.85Gbps for generating ANN results, with corresponding packet loss rates of approximately 0.02% and 0.13%. The CNN model has produced a maximum processing speed of 8.38 Mbps during the tests, corresponding to 16,895 packets per second.

C. Smart Contract

1) Transaction Cost

The smart contract is compiled using Remix IDE with compiler version 0.8.0. The contract’s constructor function is initialized with the number of maximum admins and devices at 64 and 65,535, respectively. The Simulator generates transactions and interacts with the Blockchain Server through the SSH Gateway, as shown in Figure 10. The contract deployment transaction was successfully minted in block 1 with 3,025,154 gas units spent. Table 5 shows the average gas units spent and the transaction time (seconds) to perform the associate contract function calls.

TABLE 5 The gas used and transaction time of functions in the smart contract

Transaction time is measured when the Simulator creates a transaction and sends it over the internet via the SSH Gateway to the Blockchain Server. This time value fluctuates between 0.05 to 0.14 seconds. Regarding transaction cost, the editAdmin function requires the lowest gas fee, averaging around 30,028 gas units per transaction, while other functions consume between 31,734 and 48,689 gas units on average. The requestMonitor function needs at least 41,471 and can use up to 214,280 gas units, depending on whether the device address is at the beginning or the end of the device array being queried.

2) Device Verification

In this test, we measure the device verification time on the smart contract. We double the number of admins in each trial (from 1 to 64 admins). Each admin manages a maximum of 20 gateways and 50 edge devices, which are generated randomly. The test started at Block 606 and finished at Block 3,107, in which a total of 64 admins, 650 gateways, and 1,745 edge devices were added. The total gas units used is 121,200,664. Figure 12 shows the test results in detail. The horizontal axis presents the number of admins; the left and right vertical axes indicate the total number of devices and the verification time, respectively.

FIGURE 12.

The device verification time on the smart contract in different scenarios.

At the beginning of the test, it takes 64 seconds to verify one admin and 46 devices. This number increased to 170 seconds when there were eight admins and 319 devices. The verification time linearly increased along with the total number of devices. In the last trial with 64 admins and 2,395 devices, the verification time is recorded as 1,040 seconds. Figure 13 illustrates a generated topology in the first trial where each number is mapped with an EVM address.

FIGURE 13.

The connection topology generated from Blockchain data in the first scenario.

Next, we measure the transaction time and the cost to store up to 65,535 new devices on the Blockchain. The test started from block 3,108 and ended at block 68,642, with a total of 65,535 devices added. The test result is shown in Table 6. The transaction time (seconds) and gas units are recorded as 48.6 and 49,105,376, respectively, to add 1,024 devices. By doubling the number of new devices each time, the transaction time and the gas units are likely to be doubled. At the end of the test, after 65,535 devices are added, the corresponding transaction time (seconds) and transaction cost (gas units) are recorded as 3,339.61 and 3,188,724,368.

TABLE 6 The total transaction time and gas cost when adding more devices

3) Platforms Comparison

This test compares inference time (processing time) between CPU (Intel(R) Xeon(R) Platinum 8276 CPU @ 2.2GHz x 112), GPU (NVIDIA Quadro GV100) and FPGA hardware (Alveo U280). The test scenario can be explained as follows:

1. Network packets in the IoT-23 dataset are selected for replaying back to the system. These packets belong to three benign scenarios, namely CTU-Honeypot-Capture-4-1, CTU-Honeypot-Capture-5-1 and CTU-Honeypot-Capture-7-1. Table 7 briefly shows the scenario information, including the total file size and the number of packets.

2. The CPU and GPU in the Blockchain Server host machine are used in this test. The network packets in the pcap format are read from the host machine storage and then fed to the inference model sequentially to simulate the real-time network incoming flow. The inference procedure is described in Section II-B4, which introduces pre-processing and processing time. The pre-processing time includes the CPU processing time for reading network packets and extracting input features. The processing time comprises data transfer and actual inference time.

3. The FPGA inference time is measured on the Security Admin host machine. The Ethernet Card is used to replay network packets at high speed. For testing our secure cores, we set a speed limit in replaying the packets; these limits are 2Gbps and 5Mbps for measuring ANN and CNN cores, respectively. Table 8 shows the routing information programmed on the FPGA Gateway in which raw packets will be forwarded to the physical interface - NF1 while security cores will send the results using virtual interfaces through the DMA route.

TABLE 7 The pcap file’s information

TABLE 8 The routing information programmed on the FPGA Gateway

The experimental results of CTU-Honeypot-Capture-4-1, CTU-Honeypot-Capture-5-1 and CTU-Honeypot-Capture-7-1 scenarios are correspondingly illustrated in Figure 14, Figure 15 and Figure 16.

FIGURE 14.

The inference results between engines in the first scenario.

FIGURE 15.

The inference results between engines in the second scenario.

FIGURE 16.

The inference results between engines in the third scenario.

Overall, the ANN model on FPGA shows an average speedup of 26.8 and 44.3 times that of the CPU and GPU used in this experiment. When the CNN model is used, the speedup is reduced to 1.8 and 2.2 times compared to the ANN model. In the first scenario, it takes 0.89 seconds for the FPGA Gateway to process 30,189 packets with an average packet size of 231B at the sending speed of 2Gbps. There is overhead in data pre-processing on the CPU that added approximately 251% and 100% to the total inference time of CPU and GPU, respectively. All scenarios have shown similar result patterns in which the FPGA card is the fastest in processing network packets. This is because the FPGA device used is specialized for networking applications. Additionally, data pre-processing is implemented on hardware using hardware description languages; while the CPU and GPU incur significant overhead in data preprocessing and data transfer between memories. ML models on CPU and GPU platforms only achieve optimal performance when input data is bundled, which is not applicable in real-time packet processing.

SECTION V. Discussion

The proposed architecture includes security enhancement at different layers, enhancing protection from the edge to the cloud of an IoT network. Below, we discuss the advantages and disadvantages of the implemented system by layers.

A. The Cloud Layer

Blockchain and smart contract technology are used for access control in IoT networks on the cloud. Blockchain is well-suited for IoT security as organizations increasingly adopt decentralized network models. In a decentralized platform, widespread adoption means more validators participating in the network, strengthening the system’s security and sustainability. This enhances data integrity and redundancy in IoT networks.

The IoT network generates a significant amount of data over time; thus, recording this data on the Blockchain is costly. This work proposes smart contracts to store management data on-chain, including administrators, devices and connections information. In addition, using smart contracts helps prevent attackers from impersonating devices or administrators since only whitelisted participants can change the smart contract’s states.

The contract owner holds the highest authority level, which is vulnerable if compromised. This security threat can be mitigated using the multi-signature technique, in which a group of administrators replaces the owner, and the majority must approve each function call in the smart contract before execution. Furthermore, a smart contract can be updated without changing the original contract address using the proxy technique. This enhances flexibility and security since the smart contract is upgradeable.

B. The Control Layer

Smart contracts allow administrators to operate in a distributed manner while maintaining data synchronization. Approved Web3 admins can quickly query IoT network data and participate in network governance. Similarly, security admins can contribute equally through smart contracts. This approach enhances the system’s scalability in a cost-effective manner. However, there is a collision when different admins make different decisions on the same task, particularly if one of the admins has compromised their private key. In such cases, an action is required to detect and remove the compromised admin from the admin list.

At the current stage, an administrator must supervise and add new devices to the smart contract after monitoring results from the anomaly-based IDS. A better handshaking mechanism between the Blockchain and anomaly-based IDS is needed for an automatic system.

C. The IoT Devices Layer

Although the ANN model has shown an outstanding performance thanks to the pipeline design on FPGA, the CNN model has experienced overhead in feature extraction and post-processing. The CNN model performance can be improved by either redesigning the CNN model on FPGA or changing the priority in the Packet Selector module.

The Gateways are designed on programmable FPGA-based hardware accelerators, resulting in enhanced flexibility in designing and updating security functions. However, the Alveo U280 device used in this study demonstrates high-speed processing capability; it is a high-end device with high production costs, which may pose challenges for practical applications.

The edge devices in this study are currently in a simulated state, and a practical system would encounter additional challenges. For instance, most traditional devices are limited in computational power, making it impractical to manage the EVM key for Blockchain authentication. Consequently, the administrators in the control layer must ensure that the mapping process is accurate and secure.

SECTION VI. Conclusion and Future Work

This paper proposes a scalable security approach that combines Blockchain and anomaly-based IDS using hardware accelerators for IoT networks. The implemented system has demonstrated the comprehensive protection approach from the edge to the cloud in an IoT architecture. Here, we conclude the work and discuss future directions.

Firstly, Blockchain and smart contracts are proposed for IoT access control on the cloud. The Blockchain provides a transparent, immutable and decentralized computing environment for administrators to control IoT devices in the network. The smart contract includes two authorization levels for managing administrators and IoT devices. We have measured the smart contract’s transaction costs and response time in different test cases. The experimental results showed that the implemented system effectively manages administrators and devices according to defined rules in the smart contract, in which only authorized entities can access the system. Future work will explore adding security features for smart contracts, such as multi-signature and proxy access.

Secondly, we have proposed an anomaly-based IDS for edge devices. We propose using lightweight machine learning models on FPGA hardware acceleration for Gateways. The prototype FPGA-based Gateway, which contains ANN and CNN detection models, was deployed on the Alveo U280 card (NetFPGA-PLUS) to evaluate the proposed architecture. The ANN model has achieved the highest processing speed at 20Gbps with a packet loss rate of approximately 0.13%. The CNN model has produced a maximum processing speed of 8.38 Mbps, corresponding to 16,895 packets per second. The CNN architecture on FPGA can be redesigned in a pipeline fashion for better performance in the next version.

Finally, the research indicates that combining Blockchain and anomaly-based IDS significantly enhances scalable security in IoT networks. The anomaly-based IDS can detect attacks early at the edge level using hardware accelerators, while the smart contracts on Blockchain help manage and scale the system effectively in a secured and decentralized manner. We have tested the proposed approach regarding the scalable capability across different layers. The experimental results show that Blockchain and smart contracts provide a secure, decentralized, and scalable environment for exchanging IoT management data. At the same time, the anomaly-based IDS on FPGA hardware can detect attacks in the high-speed network environment using machine learning models. The proposed approach can be applied to large-scale secure IoT deployment in real-world case scenarios.

ACKNOWLEDGMENT

The authors acknowledge the Insight SFI Research Centre for Data Analytics at University College Cork, Ireland. Support from Qualcomm through a philanthropic gift is also acknowledged. We would also like to acknowledge the support from Analog Devices, AMD/Xilinx, and Dell for various parts of this project. This research acknowledges the indispensable role that “ChatGPT (GPT-3.5)” and “Grammarly” played in the development of this study. Their assistance has proven extremely beneficial, enhancing the overall quality and depth of the research. We used these tools for language refinement, grammar checking, and enhancing the clarity of writing.