Source-linked AI summary
HBFL: A Hierarchical Blockchain-based Federated Learning Framework for a Collaborative IoT Intrusion Detection
Mohanad Sarhan, Wai Weng Lo, Siamak Layeghy, Marius Portmann
TL;DR
Privacy and security concerns make it difficult for organizations to share the data needed for collaborative ML-based intrusion detection. HBFL combines hierarchical federated learning with a permissioned blockchain and smart contracts to support inter-organizational threat-intelligence sharing while keeping training data local. In the reported evaluation, the HBFL model detected the full set of attack classes, unlike non-CTI scenarios that unreliably detected some unseen attacks.
Problem
Sharing the benign and malicious training data needed for inter-organizational CTI is difficult for ML-based IDS because of privacy and security concerns.
Source: §1 · p. 2Method
HBFL uses hierarchical federated learning across IoT endpoints, combiners, and a reducer, with blockchain and a smart contract coordinating the process.
Source: §1 · p. 2Results
The HBFL global model detected the full set of attack classes, while non-CTI scenarios unreliably detected some unseen attacks; its added privacy and security mechanisms did not impact detection accuracy.
Source: §5.3 · pp. 15–16Takeaways & Limitations
The evaluation indicates that HBFL can support collaborative IoT intrusion detection using shared threat intelligence while preserving the privacy of sensitive training logs.
Source: §1 · p. 2, §5.3 · p. 16Traditional federated learning’s reliance on one global server raises scalability concerns for large deployments and can create a single point of failure.
Source: §2.2 · p. 4
Abstract
from arXiv · showhide
The continuous strengthening of the security posture of IoT ecosystems is vital due to the increasing number of interconnected devices and the volume of sensitive data shared. The utilisation of Machine Learning (ML) capabilities in the defence against IoT cyber attacks has many potential benefits. However, the currently proposed frameworks do not consider data privacy, secure architectures, and/or scalable deployments of IoT ecosystems. In this paper, we propose a hierarchical blockchain-based federated learning framework to enable secure and privacy-preserved collaborative IoT intrusion detection. We highlight and demonstrate the importance of sharing cyber threat intelligence among inter-organisational IoT networks to improve the model's detection capabilities. The proposed ML-based intrusion detection framework follows a hierarchical federated learning architecture to ensure the privacy of the learning process and organisational data. The transactions (model updates) and processes will run on a secure immutable ledger, and the conformance of executed tasks will be verified by the smart contract. We have tested our solution and demonstrated its feasibility by implementing it and evaluating the intrusion detection performance using a key IoT data set. The outcome is a securely designed ML-based intrusion detection system capable of detecting a wide range of malicious activities while preserving data privacy.
1 Introduction
IoT security is challenged by sensitive data and distributed attack surfaces, while privacy and security concerns constrain organizations’ sharing of threat intelligence for ML-based intrusion detection. HBFL combines hierarchical federated learning, blockchain, and smart contracts for collaborative detection without exchanging local training data; the paper reports feasibility on an IoT IDS dataset.
1 Introduction
- CTI sharing for ML-based IDS is limited by privacy and security concerns, despite its potential to improve attack detection.ML-based IDSs use behavioral patterns to distinguish benign from malicious activity.Source: §1 · p. 2
- HBFL enables organizations to benefit from one another’s threat intelligence while keeping sensitive training logs internal through federated learning.Federated learning trains a common model across endpoints locally, without local data exchange.Source: §1 · p. 2
- HFL adds a middle layer of combiners that aggregate model weights between organizational IoT endpoints and the global reducer, supporting large-scale deployments.The framework places endpoints, combiners, and the reducer at the edge, fog, and cloud, respectively.Source: §1 · p. 2
- A permissioned blockchain and smart contract orchestrate HBFL tasks, verify that they conform to planned criteria, and record transactional details on an immutable ledger.The framework is designed to avoid reliance on a single trusted orchestrator.Source: §1 · p. 2
- The framework’s stated benefits include secure inter-organizational CTI, privacy for local IoT logs, scalability, and avoiding a single trusted orchestrator.The paper also describes the architecture as securely designed and intended for practical deployment.Source: §1 · p. 2
- HBFL was implemented and evaluated on a key IDS dataset, with the authors reporting feasibility and efficiency.The evaluation compares collaborative and non-collaborative scenarios.Source: §1 · pp. 2–3
2 Background
The background motivates organizational CTI sharing for ML-based intrusion detection while explaining how federated learning can protect local data and how blockchain and smart contracts support collaborative processes.
2.1 Cyber Threat Intelligence
- CTI sharing lets organisations learn from others’ attack experience, but ML-based IDS collaboration needs multiple organisations’ benign and malicious training data, raising privacy and security concerns.Without CTI, local experience may not generalise across non-IID data, and gathering enough samples can be difficult for small organisations.Source: §2.1 · p. 3
2.2 Federated Learning
- Federated learning trains across endpoints without exchanging their local datasets, exposing models to heterogeneous data while protecting endpoint privacy.Centralised learning can use heterogeneous data but requires collecting and sharing logs, whereas localised learning may not generalise across non-IID endpoints.Source: §2.2 · pp. 3–4
- FedAvg aggregates client model updates at a global server and is described as robust to non-IID and unbalanced data and efficient for communication-limited endpoints.Clients update model weights locally over E epochs before the global server aggregates received weights.Source: §2.2 · p. 4
2.3 Blockchain
- Blockchain provides distributed, tamper-resistant transaction records, while permissioned networks restrict access and smart contracts can monitor and execute agreed tasks.Smart contracts offer a shared agreement for coordination without relying on a trusted intermediary.Source: §2.3 · pp. 4–5
3 Related Work
Prior work combines blockchain and federated learning for IoT detection, privacy, or collaboration, but the surveyed approaches often use standard federated architectures, public chains, or lack CTI-focused collaboration.
Blockchain and federated-learning IDSs
- Cui et al. combine public blockchain, federated learning, and differential privacy for IoT anomaly detection, but evaluate on the outdated KDD-CUP dataset.The review notes that this 1999 dataset does not represent modern IoT attack behaviour.Source: §3 · p. 5
- Lu et al. use a permissioned blockchain to control access to model updates and evaluate data categorisation, with aggregation time increasing as providers add local models.Source: §3 · p. 5
Industrial and hierarchical approaches
- Zhang et al. evaluate CDW FedAvg on an industrial partner dataset and report that it outperforms traditional FedAvg in that use case.The method weights aggregation using distances between positive and negative classes; a smart contract rewards clients based on data size and centroid distance.Source: §3 · p. 6
- Chai et al. report about 10% better sharing efficiency and learning quality than traditional federated learning, while Saadat et al. report HFL superiority across three NSL-KDD assignment cases.Saadat et al. report faster convergence, lower loss, and higher testing accuracy for HFL.Source: §3 · p. 6
CTI and blockchain evaluation
- Preuveneers et al. find blockchain adds a 5%–15% performance impact in federated intrusion detection, while Sarhan et al. [27] report federated results above localised but slightly below centralised learning.The cited Sarhan framework evaluates collaboration on two NetFlow IDS datasets used together in parallel.Source: §3 · p. 6
Research gap
- The review identifies a gap: most surveyed frameworks use standard rather than hierarchical federated learning, many use public blockchains that expose model weights, and few automate server roles with smart contracts.Only one cited paper is described as targeting CTI sharing for organisations using ML-based IDSs.Source: §3 · pp. 6–7
4 Hierarchical Blockchain-based Federated Learning
HBFL combines hierarchical federated learning with permissioned blockchain orchestration so organisations can share threat intelligence while retaining endpoint data locally. Its design uses local and global aggregation, smart-contract monitoring, and reducer and combiner roles.
4 Hierarchical Blockchain-based Federated Learning
- HBFL combines heterogeneous organisational IoT logs into a global IDS model intended to improve generalisation and detection of threats unseen locally, while keeping sensitive endpoint data within each organisation.The framework uses a permissioned blockchain smart contract to coordinate the process without requiring organisations to trust one another to mediate it.Source: §4 · p. 7
4.1 Privacy Preserving and Secure Learning
- HFL adds organisational combiners between endpoints and the reducer, supporting scale and local control while containing endpoint updates and poisoning attempts within organisational boundaries.If a reducer fails, unaffected organisations can continue using their locally aggregated models; local aggregation rounds precede global aggregation and are intended to reduce global rounds.Source: §4.1 · p. 8
4.2 Blockchain-based Orchestration and Conformance
- A permissioned blockchain hosts the reducer, verifies organisational identities and access, records weight updates immutably, and uses smart contracts to monitor and validate agreed interactions.Parameters are checked for anomalies before global aggregation, and the global model is returned to participating organisations.Source: §4.2 · p. 9
4.3 Implementation
- Reducer tasks run on-chain, while combiner and endpoint operations run off-chain; their reported status supports accounting, monitoring, and workflow progression.The contract’s Start, Hold, End, and Monitor messages trigger tasks, coordinate required completions, and record or terminate non-conforming processes.Source: §4.3 · pp. 9–10
4.3.1 Reducer
- The reducer selects active organisations, aggregates their local parameters with FedAvg, and sends updated global parameters back to them.The smart contract monitors on-chain reducer and off-chain combiner tasks against agreed criteria.Source: §4.3.1 · p. 10
19 End Reducer process
Each combiner coordinates participating endpoints within one organisation, aggregates their model updates locally, and returns global updates to those endpoints.
4.3.2 Combiner
- Combiners run off-chain in organisational fog zones, where communication with IoT clients is more efficient than with cloud servers.Source: §4.3.2 · p. 10
- Each combiner selects connected endpoints with reliable communication, aggregates their trained parameters using FedAvg, and sends local parameters to the reducer.The active endpoint set can be adjusted to online endpoints during a given period.Source: §4.3.2 · pp. 10–11
- After receiving updated global parameters, a combiner sends them back to its endpoints.Source: §4.3.2 · p. 10
1 Start(Taskc)
The sequence selects active and participating IoT endpoints, then initiates the endpoint process.
1 Start(Taskc)
- Active and participating IoT endpoints are selected.This is step 2.Source: §1 · p. 11
- The endpoint process is initiated next.This is step 3.Source: §1 · p. 11
5 Start(Taskd)
The task flow waits for its tasks to complete, sends aggregated local parameters to the reducer, and returns aggregated global parameters to endpoints. Endpoints train locally, while the hierarchical blockchain design describes monitoring, containment, and integrity protections.
5 Start(Taskd)
- The flow holds until all listed tasks report completion.It then sends aggregated local model parameters to the reducer and aggregated global parameters to endpoints.Source: §5 · p. 11
4.3.3 Endpoint
- Endpoints train on local data and send updated parameters to their combiner, then receive globally aggregated parameters for intrusion detection.Endpoint health is the parent organisation’s responsibility and is not monitored by the smart contract; validating endpoint health through combiners is future work.Source: §4.3.3 · p. 11
4.4 Security Analysis
- The monitor scans organisational parameters for anomalies, discards anomalous updates, and can stop the next task; hierarchical segmentation contains adversarial activity within the originating network.The specific anomaly-detection technique, such as k-means clustering, is left for future work.Source: §4.4 · p. 12
- Endpoint weights stay within the organisational perimeter, while a permissioned ledger makes uploads traceable and cryptographic mechanisms protect recorded transactions and model weights from manipulation.Only registered organisations with unique IDs can upload and verify global parameters.Source: §4.4 · p. 12
5 Experimental Evaluation
The evaluation compares HBFL with non-collaborative federated learning on two organizations’ IoT datasets containing different attack classes. HBFL’s shared CTI scenario reports stronger detection results than the non-collaborative scenarios.
5.1 Setup
- The IDS uses a four-middle-layer Deep Feed Forward model with ReLU activations, a sigmoid output, and Adam optimization; hyperparameter tuning is out of scope.The data is split 70% for training and 30% for testing, with mean metrics reported across repeated test-set evaluations.Source: §5.1 · p. 12
- The experiment uses NF-BoT-IoT-v2, a NetFlow-based dataset with 37,763,497 samples across DDoS, DoS, reconnaissance, and theft attack groups.The dataset contains 99.64% attack samples and 0.36% benign samples.Source: §5.1 · p. 13
- The use case has two organizations with datasets containing different attack classes; it compares cross-organization training and testing with HBFL training and evaluation on both datasets.The attack-class distribution is presented in Table 3.Source: §5.1 · p. 13, Table 3 · p. 13
5.2 Results
- Scenario 1 reported 95.77% accuracy for DoS and 63.88% for theft, while Scenario 2 reported DDoS and reconnaissance F1 scores of 98.94% and 58.85%.The authors describe theft and reconnaissance detection as unreliable in these non-collaborative settings.Source: §5.2 · p. 14, Figure 3 · p. 14, Figure 4 · p. 14
- HBFL nearly fully detected all attack classes with minimal FAR; reconnaissance reached a maximum detection accuracy of 90.46% after eight rounds.Performance increased significantly after one round and then stabilized fairly.Source: §5.2 · p. 14, Figure 5 · p. 15
- 60.53% and 71.1% were the mean detection rates for Scenarios 1 and 2; HBFL reported 99.71% mean accuracy per attack class and a lower FAR.The authors characterize HBFL as superior to the other scenarios.Source: §5.2 · pp. 14–15, Table 4 · p. 15
5.3 Discussion
- The discussion attributes the non-collaborative gap to unreliable detection of unseen theft and reconnaissance classes, while noting that HBFL’s privacy and security mechanisms did not affect detection accuracy.The authors explain full DDoS and DoS detection in the non-collaborative cases by similarities between those attack classes.Source: §5.3 · pp. 15–16
6 Conclusion
HBFL is a CTI-enabling framework for ML-based intrusion detection that combines hierarchical federated learning with permissioned blockchains. Its implementation was evaluated on a key dataset, and future work includes an adversary-detection model using k-means clustering in combiners.
6 Conclusion
- The implemented framework was evaluated for intrusion-detection performance using a key dataset, and the authors describe its outcome as a robust, high-performance, securely designed ML-based IDS.The stated aim is to protect and preserve the integrity of IoT networks.Source: §6 · p. 16
- HBFL combines hierarchical federated learning and permissioned blockchains in a cloud-fog-edge topology, placing IoT endpoints, combiners, and the reducer at the edge, fog, and cloud, respectively.Source: §6 · p. 16
- A smart contract checks that executed tasks conform to predefined acceptance criteria.Source: §6 · p. 16
- Future work includes implementing an adversary-detection model using k-means clustering in the combiners.Source: §6 · p. 16