In the considered IIoT environment, the federated learning system is exposed to multiple categories of adversaries with varying objectives and capabilities. (1) Poisoning adversaries aim to manipulate the global model by injecting falsified or low-quality updates, thereby degrading learning accuracy or biasing model outcomes. (2) Sybil or impersonation attackers attempt to create multiple fake identities or reuse compromised credentials to distort the aggregation process or flood the federation with malicious nodes. (3) Free-rider participants try to obtain model benefits without contributing meaningful updates, exploiting trust among peers. In addition, eavesdropping and inference adversaries may seek to reconstruct private client data through gradient leakage or side-channel analysis. Together, these behaviors represent the key threats that motivate the design of Leash-FL’s certificateless authentication, blockchain auditability, and self-healing mechanisms to ensure confidentiality, integrity, and resilient operation in distributed IIoT environments.
This paper aims to present a lightweight ECC-based self-healing federated learning framework for secure IoT systems, termed Leash-FL. Modern IoT deployments remain vulnerable to identity spoofing, poisoned or free-rider updates, and Sybil attacks, while most defenses lack autonomous recovery. Leash-FL addresses these challenges by combining certificateless ECC-based authentication with similarity-governed pre-aggregation screening and a blockchain-assisted self-healing controller that can roll back and reconfigure training without service interruption.
3.1. Overview of the Proposed LEASH-FL Framework
Figure 1 illustrates the overall architecture of the proposed Leash-FL framework, which operates across three collaborative layers: device, edge, and cloud.
At the device layer, heterogeneous IoT endpoints (sensors, wearables, meters, and vehicular nodes) locally train models on private data and transmit only signed model updates authenticated through pseudonymized certificateless ECC credentials. Each update is timestamped to ensure freshness and accompanied by lightweight training-effort metadata. Raw features and labels never leave the device, preserving data privacy and unlinkability across rounds.
The edge layer hosts gateway nodes that act as local coordinators. They verify signatures and timestamps, execute similarity-governed screening to filter low-effort or anomalous submissions, and record audit proofs (hashes, signatures, timestamps, and verdicts) on a lightweight consortium blockchain for tamper-evident auditing and membership governance. Only verified updates are forwarded to the cloud for aggregation.
The cloud layer performs weighted aggregation of validated updates to produce the global model and maintains signed checkpoints to enable rollback and self-healing when anomalies are detected. It coordinates revocation and reconfiguration through blockchain-backed control, refreshing pseudonyms and group keys for affected devices without exposing sensitive model parameters.
Together, these layers establish a continuous, privacy-preserving, and tamper-resistant federated learning process that supports dynamic IoT environments. They collectively enable system initialization, authenticated training, edge-side verification, blockchain-based audit, global aggregation, self-healing, redistribution, and adaptive membership management. The detailed operational flow—corresponding to these nine sequential stages—is described in
Section 3.1.1,
Section 3.1.2,
Section 3.1.3,
Section 3.1.4,
Section 3.1.5,
Section 3.1.6,
Section 3.1.7,
Section 3.1.8 and
Section 3.1.9.
3.1.1. System Initialization and Credential Management
The initialization and credential management module forms the cryptographic foundation of Leash-FL, ensuring that only authorized IoT devices can participate in federated learning while maintaining privacy, unlinkability, and scalable key management. It encompasses four main components: system setup, pseudonym generation, certificateless key establishment, and dynamic membership management.
During
system setup, a trusted authority (TA) defines an elliptic-curve group
of order
with base point
, chooses a master secret
, and computes the public key
which serves as the root of trust for all participants. The TA also defines several cryptographic hash functions
used for pseudonym binding and key derivation. These parameters
are publicly distributed, while the master key
remains secret.
In the pseudonym generation stage, each device with identity receives a pseudonym that conceals its real identity while maintaining accountability. The pseudonym is computed through a hash-binding process that links with a random seed and a time validity token. This ensures that even if updates from the same device appear in consecutive rounds, their pseudonyms remain unlinkable. When the validity window expires.
Certificateless key establishment eliminates the need for traditional public-key certificates. The TA generates a partial private key for each device, while the device independently produces its own secret and combines the two to form a complete signing key pair. The hash of the pseudonym and public parameters acts as a linking factor, enabling any verifier to authenticate the signature without relying on a certificate chain. This dual-source key generation prevents key escrow and protects against impersonation by ensuring that neither the TA nor the device alone possesses the complete key. The specific mathematical expressions for the key generation and verification process are provided in
Appendix B.1 (Equations (A1) and (A2)).
Dynamic membership management handles secure joining, leaving, and rekeying of devices in the network without interrupting training. Leash-FL employs a Chinese Remainder Theorem (CRT)–based rekeying protocol in which each participant is assigned a unique modulus, and all moduli are pairwise co-prime. When a member joins or leaves, the cloud generates a composite modulus and distributes a new rekey parameter that allows only active members to reconstruct the updated key while excluding revoked ones. The group-key consistency condition is expressed as
where
denotes the revoked node. The full CRT derivation and its correctness proof appear in
Appendix B.1 (Equation (A3)). This rekeying design guarantees both forward secrecy (revoked nodes cannot compute future keys) and backward secrecy (new nodes cannot access past models).
To maintain transparency, all membership updates, key-refresh events, and revocation records are anchored on a lightweight blockchain maintained at the edge. Each transaction logs the pseudonym, event type, and validity period of the rekeyed group secret, forming an immutable record of system reconfiguration.
Through this integrated ECC–CRT initialization, Leash-FL achieves secure pseudonymized participation, certificate-free key generation, and privacy-preserving rekeying. This foundation ensures that all subsequent phases—training, verification, and aggregation—operate within a trustworthy cryptographic domain, balancing efficiency with verifiable security.
3.1.2. Local Training and Authentication
Once initialization and credential management are completed, each IoT device participates in federated learning by training on its local dataset and producing authenticated model updates for aggregation. This module guarantees that raw data always remains on the device, while only signed parameter updates and lightweight metadata are transmitted for validation.
At the beginning of round
, each device
receives the authenticated global model parameters
from the cloud through the edge coordinator and updates them locally using stochastic gradient descent (SGD). After several epochs, the new model parameters are:
where
is the learning rate,
is the local dataset size, and
denotes the loss function. This expression defines the local update
that is later shared with the federation.
After training, the device signs its update using its certificateless key pair. The signing process involves computing a hash-based authentication coefficient and a lightweight ECC signature derived from the current group key. The detailed mathematical signing and message-construction steps are listed in
Appendix B.2 (Equations (A4)–(A6)). Each signed message includes the updated model
, the pseudonym
, and a timestamp
to ensure freshness.
The signature’s correctness is verified at the edge or cloud using:
where
and
originate from the certificateless key generation, and
is the TA’s public key. This relation confirms the authenticity and integrity of each update and prevents forgery or impersonation. Here, “∗” denotes elliptic curve scalar multiplication.
The local training and signing phase enforces several security guarantees. Data privacy is preserved because raw features never leave the device. Authenticity and integrity are ensured through ECC-based signatures, while non-repudiation prevents a device from denying participation once its update is recorded. Training-effort metadata attached to each signed message deters free-rider attacks by making it infeasible to submit random or untrained updates. Including timestamps defends against replay attempts, allowing the edge layer to reject stale submissions. Collectively, these safeguards ensure that only valid, authenticated, and timely updates participate in aggregation, providing the foundation for secure and reliable model training in Leash-FL.
3.1.3. Edge-Side Verification and Screening
Upon receipt of a signed message , the edge coordinator first enforces timeliness. Messages are accepted only if their timestamps fall within the configured freshness window; otherwise, they are discarded as stale or replayed. This freshness check, consistent with the timing logic used for FL control packets, is performed before any cryptographic operation to minimize computation overhead.
For messages that pass freshness verification, the edge authenticates the sender using the certificateless signature relation
where
,
, and
. This equality holds only if the update originates from a legitimate device possessing valid keys. Invalid or replayed messages are rejected immediately. When multiple updates arrive simultaneously, the edge performs
batch verification to amortize elliptic-curve computations and sustain throughput. Additional details of this process are summarized in
Appendix B.3 (Equations (A7) and (A8)).
After authentication, the edge performs
similarity-governed screening to suppress low-effort or anomalous updates. For the round’s candidate set
, each update is compared to a robust reference
(e.g., the coordinate-wise median) using cosine similarity,
Updates with are flagged as potential outliers. Magnitude checks then evaluate the update norm and discard any whose scale deviates beyond the configured thresholds. When a small validation buffer is available, the contribution quality is also estimated through local loss reduction, ; updates showing modest improvement are down-weighted rather than rejected. The resulting verdicts are classified as with associated weights .
All screening outcomes are immutably recorded on a lightweight blockchain distributed across edge servers. Each record includes the hash of the submitted update, pseudonym, timestamp, and verdict, ensuring accountability and traceability while model tensors remain stored off-chain to preserve efficiency and confidentiality. Finally, the edge forwards the screened and weighted batch to the cloud, together with a reference to the blockchain transaction for traceability. This guarantees that only fresh, authenticated, and similarity-consistent updates participate in global aggregation while every step remains auditable.
3.1.4. Blockchain-Based Audit and Membership Management
In Leash-FL, a permissioned blockchain deployed across edge servers maintains an immutable audit trail and decentralized membership control. After edge-side verification and screening, each round’s accepted or rejected updates are encapsulated as metadata records linked to the ledger. For a device
, the record includes the hash of its submitted update, pseudonym
, timestamp
, and screening verdict
. The record hash is defined as
where
denotes a collision-resistant hash function. These digests form candidate blocks for the round, and consensus is reached through validation votes among a committee of edge nodes. Each edge
verifies the update Δ
and casts a binary vote; the formal tally process is provided in
Appendix B.4 (Equation (A9)). An update is committed once a majority of edges approve it.
To preserve ledger integrity, each block
is linked to its predecessor through a cryptographic digest such that
for any tampered log
. This condition ensures that unauthorized alterations in the audit trail are immediately detectable by hash mismatch across replicas.
Membership management is integrated into the same ledger. Each participant is assigned a CRT-based modulus and contribution that enables group-key updates during join or leave events. When a member is revoked, its contribution is removed and a new key is computed from the remaining set, while new devices contribute fresh CRT components to the sum. The detailed formulas for these operations are listed in
Appendix B.4 (Equations (A10) and (A11)). This procedure guarantees forward secrecy (revoked devices cannot compute future keys) and backward secrecy (new devices cannot reconstruct previous ones).
By anchoring membership events and rekeying transactions on-chain, Leash-FL provides tamper-proof auditability and verifiable synchronization across edges. Only metadata and hash digests are stored on the ledger, keeping storage and communication overhead bounded while preserving transparency, accountability, and trust for all participants.
3.1.5. Security Model and Proof Sketches
We define the security model of Leash-FL under standard assumptions in certificateless public-key cryptography and federated learning. The adversary is modeled as a probabilistic polynomial-time (PPT) adversary capable of compromising up to a fraction of clients (10–50%) and controlling their local training. It may request chosen-message signatures (CMA), replay stale updates, spawn multiple pseudonyms (Sybil), or read all blockchain data but cannot modify committed transactions because of consensus guarantees. The adversary cannot derive private keys unless it can solve the Elliptic Curve Discrete Logarithm Problem (ECDLP), which is assumed infeasible.
The security objectives of Leash-FL are fourfold. First, it ensures authenticity and integrity, meaning that only legitimate clients can produce and submit accepted model updates. Second, it guarantees unforgeability, preventing any adversary from generating valid signatures without the corresponding private keys. Third, it provides forward secrecy, ensuring that revoked clients cannot derive session keys or access future updates after being removed from the federation. Finally, it maintains backward secrecy, preventing newly joined clients from reconstructing or accessing past session keys and model parameters. All proofs are based on the correctness of the certificateless signature scheme and the CRT-based rekeying process described earlier (see
Appendix B.5 for formal definitions).
Lemma 1. (Authenticity and Integrity)
Assumption. Adversary has PPT capabilities and can intercept or modify updates but not forge ECC signatures without private keys.
Proof Sketch. Each local update includes a valid ECC signature bound to a pseudonym. Edge servers verify these signatures using public parameters before aggregation. Any modification causes signature mismatch and rejection with probability 1, ensuring authenticity and integrity.
Lemma 2. (Unforgeability)
Assumption. Adversary has access to chosen-message signing queries (CMA).
Proof Sketch. If produces a valid forgery without the private key, it would imply the ability to solve the ECDLP in group
. Because ECDLP is infeasible, the probability of forgery is negligible. Hence, the certificateless ECC signature scheme in Leash-FL is existentially unforgeable under chosen-message attack (EUF-CMA).
Lemma 3. (Forward Secrecy)
Assumption. Adversary possesses all past keys of a compromised device but no access to ongoing rekeying transactions.
Proof Sketch. Forward secrecy follows from CRT-based rekeying. Upon revocation, new session keys are generated and broadcast through the blockchain ledger; pseudonyms and partial keys are refreshed. Old keys become obsolete, preventing revoked clients from deriving future ones.
Lemma 4. (Backward Secrecy)
Assumption. Adversary represents a revoked client holding its last valid key.
Proof Sketch. After revocation, the trusted authority issues a new group key distributed only to active participants through the ledger. Revoked clients are excluded from rekeying and cannot compute fresh session keys. Since pseudonyms and secrets are refreshed, backward secrecy holds.
Under this model, Leash-FL achieves authenticity, integrity, unforgeability, and secrecy guarantees against polynomial-time adversaries. These properties are grounded in the hardness of ECDLP and the correctness of blockchain-driven rekeying.
3.1.6. Global Aggregation and Checkpointing
Following edge-side verification and similarity screening, only authenticated and quality-checked updates are forwarded to the cloud. These validated contributions form the input for global aggregation, where weighted averaging and batch verification ensure both efficiency and robustness. If anomalies are detected during or after aggregation, corrective actions are triggered through the self-healing process described in
Section 3.1.7, enabling rollback to trusted checkpoints or adaptive reconfiguration of the model. Together, these operations establish a secure end-to-end pipeline for federated learning in Leash-FL.
After receiving the screened and weighted updates
from the edge servers, the cloud verifies each blockchain reference to confirm that the updates were correctly authenticated and screened. The global model is then updated using weighted averaging, expressed as
where
denotes the dataset size, similarity score, or penalty factor assigned by the edge layer. This ensures that contributions from well-behaved devices have greater influence, while unreliable or borderline updates have proportionally less impact.
To enhance efficiency, the cloud performs
batch signature verification on multiple authenticated updates. Using a small-exponent method, all signatures are verified in a single computation step, significantly reducing elliptic-curve overhead. The detailed verification expression is provided in
Appendix B.6 (Equation (A12)).
After aggregation, the newly generated global model is stored as a checkpoint. The controller maintains a fixed number of recent checkpoints, forming a rolling window of trusted states. If future anomalies or adversarial behaviors are detected, the system can revert to the latest valid checkpoint rather than restarting training from scratch, thereby minimizing downtime and cost.
At the conclusion of each round, the checkpointing mechanism guarantees that at least one verified global model is always available for recovery. Even with robust screening at the edge and weighted aggregation at the cloud, rare adversarial updates or coordinated Sybil behaviors may still slip through. To handle such cases, Leash-FL employs a dedicated self-healing monitor that continuously evaluates the aggregated model and initiates rollback whenever anomalies are detected.
3.1.7. Self-Healing Response
To maintain resilience against malicious or corrupted updates, the cloud continuously monitors the aggregated model for anomalies. Detection relies on indicators such as sudden drops in validation accuracy, a surge in rejected updates, or deviations in similarity scores. Formally, an anomaly is triggered when the cosine similarity between a local update and the cohort reference falls below the acceptance threshold α:
where
denotes the reference model. When an anomaly is detected, the cloud activates the
self-healing response R(t), which either rolls the system back to a previously trusted checkpoint or performs adaptive reconfiguration of the model. The formal definition of R(t) is given in
Appendix B.7 (Equation (A13)).
During operation, authenticated and screened updates are aggregated through weighted averaging and batch verification. If inconsistencies appear in later rounds, the self-healing process determines whether to restore the last verified model or to adaptively exclude outliers and recompute aggregation with stricter thresholds. Rollback reinstates the latest trusted checkpoint, while reconfiguration recalibrates similarity thresholds, regenerates pseudonyms, and refreshes group keys for the affected cohort.
Each self-healing event, rollback, pseudonym refresh, key rotation, or threshold update, is immutably recorded on the blockchain ledger, providing traceability without exposing model parameters. Through this synergy of weighted aggregation, anomaly detection, and checkpoint-based recovery, Leash-FL remains resilient to poisoning, Sybil, and free-rider attacks. At the same time, blockchain-anchored logging ensures that every recovery action is auditable and tamper-evident, preserving the trustworthiness of federated learning across all participants.
3.1.8. Redistribution and Synchronization
After aggregation and self-healing, the updated global model
must be reliably disseminated to all legitimate devices. The cloud broadcasts
, where
is the hash digest for the current round timestamp
, and
is the cloud’s certificateless ECC signature. Each device verifies both freshness and authenticity of the broadcast through,
which ensures that the received model originates from the legitimate cloud and has not been altered in transit.
To maintain synchronization, each device returns a short acknowledgment containing its pseudonym and the hash of the received model. The edge aggregates these acknowledgments and writes the resulting digest to the blockchain as a tamper-evident proof of round completion. The detailed expressions for the acknowledgment and late recovery verification appear in
Appendix B.8 (Equations (A14) and (A15)).
Devices that fail to acknowledge within the round window are classified as stragglers. They can resynchronize by retrieving the last valid digest and receipt from the blockchain and requesting the corresponding model from the edge. Since all model digests are stored on-chain, any device can independently verify consistency with the global state before resuming participation.
From a performance perspective, redistribution requires only a single signature verification and one hash operation per device, keeping overhead minimal. Edge aggregation of acknowledgments scales linearly with the number of participants, while blockchain logging grows proportionally to the number of rounds. As only metadata and hashes are stored on-chain, bandwidth costs for transmitting full model weights remain low.
By combining authenticated broadcast, acknowledgment-based synchronization, and blockchain-backed recovery, Leash-FL ensures that every participant trains on the same trusted global model. This integrated design provides verifiable resistance against replay, tampering, and equivocation attacks, ensuring synchronization and consistency across the federation.
3.1.9. Dynamic Join/Leave with Re-Admission
The Leash-FL framework supports dynamic membership to accommodate the highly variable nature of IoT environments, where devices may join, leave, or require re-admission after quarantine. Membership events are coordinated through certificateless credentials, CRT-based rekeying, and blockchain-backed logging to ensure accountability, secrecy, and synchronization across training rounds.
When a new device
is admitted, the trusted authority issues a fresh pseudonym
and a corresponding certificateless key pair. The controller integrates the new device into the federation by extending the CRT-based rekeying process previously described in
Appendix B.4 (Equations (A10) and (A11)). These same relations govern both join and leave events: adding a new participant contributes a fresh CRT component to the global accumulator, while revocation or voluntary departure removes the corresponding term. As a result, active members derive an updated group key, newly admitted devices gain access only to the current key, and revoked devices lose the ability to compute future ones—preserving both forward and backward secrecy.
When a device misbehaves, its pseudonym and corresponding CRT component are excluded, and a new group key is distributed solely to active members. For repeated misconduct under rotating pseudonyms, the trusted authority can resolve the true identity from the pseudonym–timestamp mapping and permanently revoke the device from future participation.
All membership events—including joins, leaves, rekeying operations, and re-admission—are immutably recorded on the blockchain ledger. Each transaction logs the pseudonym, event type, validity period, and rekeying version, creating an auditable history of membership evolution without exposing private data. Devices placed in quarantine may later be re-admitted following successful re-attestation of credentials. Re-admission is treated as a fresh join, involving a new pseudonym issuance and CRT-based reintegration to prevent access to any previous session keys.
Through this integrated mechanism, dynamic membership management in Leash-FL achieves scalability, accountability, and robustness. Joins and leaves are processed efficiently using modular CRT arithmetic, while blockchain consensus provides tamper-proof traceability across membership churn. This ensures that federated learning remains secure and synchronized even in highly dynamic IoT environments characterized by device mobility, heterogeneity, and adversarial behavior.
In summary, Leash-FL provides a complete end-to-end framework for secure and resilient federated learning in IoT environments. It begins with certificateless credential initialization, followed by authenticated local training, edge-side verification, and blockchain-audited screening. Weighted aggregation, checkpointing, and self-healing preserve integrity and enable adaptive recovery from anomalies, while authenticated redistribution ensures model consistency across devices. Finally, CRT-based rekeying and blockchain-backed membership management maintain forward and backward secrecy during join, leave, and re-admission events. Collectively, these components enable scalable, trustworthy, and verifiable learning across heterogeneous IoT systems.