DA³4FL: a robust dynamic accumulator-based authentication and key agreement with preserving model training data integrity for federated learning

Abstract

Federated Learning (FL) offers a privacy-preserving distributed learning paradigm by enabling model training without direct access to raw data. However, FL remains vulnerable to unauthorized access during training and client-server exchanges. Authentication and key agreement are essential to restrict access to legitimate participants. Existing FL authentication schemes are prone to impersonation risks, centralized PKI fragility, and insufficient integrity guarantees. To address these challenges, we propose DA4FL, a robust dynamic accumulator-based authentication and key agreement with preserving data integrity for FL. Specifically, our proposed DA4FL is an efficient authentication protocol utilizing dynamic accumulators, blockchain technology, and message authentication codes, which ensures robust member management, authorized access, and data integrity. Security analysis against the eCK adversary model confirms the resilience of our protocol. Furthermore, experiments and performance evaluations show the effectiveness of our method, with computational overhead competitive with current state-of-the-art (SOTA) baselines.

Introduction

Federated Learning (FL) has emerged as a promising machine learning paradigm for distributed model training, preserving the privacy of local raw data^1–3. Despite its inherent privacy advantages, FL remains susceptible to unauthorized access during transmission phases⁴, posing significant risks of privacy compromise. Essential security measures include mutual authentication to prevent unauthorized access, session key secrecy to safeguard data transmission, and integrity verification to detect model tampering⁵. Among these measures, Authentication and Key Agreement (AKA) plays a crucial role in FL, as it not only verifies the legitimacy of participating entities but also ensures secure and trusted communication. Without effective AKA mechanisms, FL systems are vulnerable to various attacks such as impersonation, man-in-the-middle, and data leakage, which can severely undermine the privacy and integrity of the learning process. Therefore, the design of robust AKA schemes is essential to establish a secure communication environment in FL.

The standard AKA workflow in FL is depicted in Fig. 1, involving three principal entities: client devices (participants), a central server (coordinator), and a trusted authority (commonly a Key Generation Center, KGC). Specifically, client devices and the server perform mutual authentication through the mediation or assistance of the KGC, followed by the establishment of a session key for secure communication. This session key is subsequently used to encrypt model updates and other sensitive information during the training process, ensuring data confidentiality and integrity against external threats. However, this conventional AKA framework faces two fundamental challenges considering security and performance perspectives.

Fig. 1.

Typical AKA framework in FL.

Challenge 1: Security weakness: most existing authentication protocols rely on a centralized Public Key Infrastructure (PKI) framework^6–8. Should the KGC be compromised or experience downtime, the entire FL system becomes vulnerable. Huang et al.’s protocol for secure data transmission in FL, while innovative, remains susceptible to this centralization issue and impersonation attacks by legitimate users⁹. On the other side, Fan et al.’s DAFL framework attempts to address decentralization in FL but lacks adequate key agreement functionality, compromising data security¹⁰. Additionally, current AKA solutions do not ensure the integrity of transmitted training data, potentially leading to failures in the FL process¹¹.

Challenge 2: Inefficient dynamic membership management: existing solutions face performance challenges from inefficient member management mechanisms. The substantial computational overhead required for authentication and key agreement impedes the model training process^12,13, particularly when frequent member additions or removals occur. Current AKA protocols typically require complete reconstruction of membership credentials during dynamic updates, which is especially problematic in FL where participant turnover is common¹⁴. While some decentralized approaches have been proposed¹⁵, they often incur significant computational and storage overhead due to frequent updates, failing to provide an optimal balance between security and efficiency.

To address above-mentioned challenges, we introduce DA4FL, a robust dynamic accumulator-based authentication and key agreement with preserving data integrity for FL. DA4FL is an efficient authentication protocol that implements four key security enhancements: (i) robust mutual authentication and decentralized trust, achieved through blockchain-secured pseudonyms, dynamic accumulators to thwart impersonation attacks¹⁶; (ii) a hybrid KGC architecture, distributing the KGC’s master secret key via Shamir’s (k, n) threshold scheme and leveraging blockchain for transparent, tamper-proof state management, which mitigates centralized issues. (iii) secure session key agreement, utilizing Elliptic Curve Cryptography (ECC) resistant to key compromise within the eCK model¹⁷; and (iv) data integrity protection, ensuring the veracity of model updates via MAC-verified methods to protect the integrity of the model training data¹⁸.

Performance-wise, the dynamic accumulator provides more efficient member management than static schemes¹⁶, allowing for real-time user additions or removals without needing to reconstruct the entire member list. The use of IPFS further optimizes the system by offloading large model storage from the blockchain, reducing costs and improving scalability. Compared to state-of-the-art methods^9,10,15, our protocol exhibits superior performance by achieving a robust balance between enhanced security, decentralization, and efficiency.

Beyond existing FL-AKA schemes (e.g.,^9,10), DA4FL (i) decentralizes trust via a thresholded KGC with on-chain state for verifiable recovery; (ii) supports efficient dynamic membership through a cryptographic accumulator with constant-time verification; (iii) preserves model-update integrity using lightweight MACs with IPFS off-chain storage; and (iv) enables quick session-key updates without full re-authentication, while remaining provably secure under the eCK model and competitive in cost.

The main contributions of this study are as follows:

• Robust dynamic accumulator-based and effective AKA protocol: We introduce DA4FL, a brand-new AKA protocol tailored for FL. The protocol ensures mutual authentication and secure encryption of model training data. It employs a dynamic accumulator for efficient member management, leverages blockchain technology for decentralization implements a robust recovery mechanism. Specifically, the KGC’s master secret key is distributed via a threshold scheme, and its state is securely backed up on-chain, enabling a new KGC to be selected and the system state to be fully restored. Additionally, the incorporation of Message Authentication Codes (MAC) guarantees the integrity of the model training data.

• Detailed security analysis: We provide a provable security proof for the DA4FL protocol under the eCK model, ensuring the semantic security of the session key. Subsequent heuristic analysis demonstrate the protocol’s robustness against diverse attacks and underscores its critical functionality.

• Extensive performance analysis: We conducted extensive experiments and performed a thorough performance evaluation of DA4FL, establishing that the protocol not only matches but frequently surpasses the performance of existing solutions. Our comparative performance analysis across five most-related authentication schemes demonstrates that DA4FL maintains competitive computational and communication costs compared to state-of-the-art protocols.

The remainder of this study is organized as follows: section “Related works” reviews the related works. Section “Problem statement” outlines the preliminary work. Section “The proposed protocol” details the proposed authentication protocol. Sections “Security analyses of the proposed protocol” and “Experiments and performance analyses” provides a comprehensive security and performance analysis of DA4FL. Finally, section “Conclusion and future work” concludes the paper.

Related works

This section presents a review of the literature on our topic, covering AKA protocols under centralized and decentralized architectures.

AKA under centralized architecture

The Public Key Infrastructure (PKI) employs centralized Certificate Authorities (CAs) to issue digital certificates, which are crucial for verifying the identities of entities⁷. This mechanism has been extensively adopted across various sectors. For instance, Siddiqui et al.¹⁹ proposed a dual-CA model to enhance security in cloud IoT systems. Similarly, Azees²⁰ and Vijayakumar²¹ have developed PKI-based protocols for anonymous vehicle authentication, and Huang et al.⁹ have incorporated PKI into their FL scheme.

However, a significant drawback of PKI is its vulnerability due to the centralized nature of certificate issuance. A single compromised CA can jeopardize the security of the entire system. Wang et al.²² emphasize that centralized PKI systems are particularly susceptible to security breaches if the CA is compromised. Additionally, traditional authentication methods such as Kerberos and OAuth, which heavily rely on central trust servers, may efficiently authenticate users but lack the robustness required to withstand large-scale attacks²³.

AKA under decentralized architecture

Some research has explored blockchain-based alternatives to address the vulnerabilities associated with centralized PKI architectures^24,25. Wang et al.²² developed a blockchain-based decentralized authentication method for smart grid edge computing that enhances data security, albeit at the expense of user anonymity. Parameswarath et al.¹⁵ introduced a user-empowered authentication scheme for electric vehicle charging that leverages decentralized identity and verifiable credentials, though it incurs considerable storage and communication costs. Similarly, Fan¹⁰ proposed a decentralized scheme for FL that lacks key agreement, compromising the security of private data. In addition, the study by Wang et al.²² also addressed the dynamic addition and removal of members, but was found inefficient in managing these changes. Each time a user joins or leaves, substantial overhead is required to update cryptographic keys and verify member credentials, which is particularly costly in FL where member updates are frequent. In response, decentralized solutions have been suggested^10,15, yet they still incur significant computational and storage overhead due to frequent updates^22,26,27.

Moreover, in FL, the aforementioned schemes primarily ensure confidentiality but fail to guarantee data integrity. Even though the model training data is encrypted using session keys, it remains vulnerable to interception by attackers who might corrupt the data sent to trainers, potentially disrupting the training and aggregation processes¹¹. Earlier methods like checksums, used to verify data integrity, lacked cryptographic robustness as they did not rely on a shared secret key, thus making them prone to forgery and collision attacks²⁸. To safeguard message integrity, digital signatures have traditionally been employed to verify the integrity and authenticity of transactions¹⁰. However, digital signatures entail significant computational and storage demands. Unlike MACs, digital signatures require asymmetric cryptographic operations, which are computationally intensive and less efficient for frequent message authentication^29,30. Decentralized authentication schemes often rely on digital signatures instead of MACs, adding to the computational load³¹. While this method ensures authenticity, it proves less efficient in resource-constrained environments like FL, where lightweight authentication mechanisms are preferred³².

Preliminaries

This section overviews the core building blocks used in DA4FL: dynamic accumulators for efficient membership management, the eCK threat model for formal security, message authentication codes (MACs) for lightweight integrity, and Shamir’s (k, n) threshold secret sharing for KGC resilience. Table 2 summarizes the notation used throughout the paper.

Table 2.

Notations of symbols in DA4FL.

Symbols	Notations	Symbols	Notations
KGC	Key generation center		Hash function
,	ith user and jth task publisher	,	Public key of ith user and jth task publisher
, ,	Private key of ith user, jth task publisher and KGC	,	Public dynamic value of ith user and jth task publisher
,	Secret dynamic value of ith user and jth task publisher	,	Pseudo identity of ith user and jth task publisher
,	Secret value pair for	,	Secret value pair for
TS	Time stamp		Maximum time to discard a request
MSK	Master Secret key of KGC	SK	Session key of ith user and jth task publisher
,	Identity of ith user and jth task publisher		Public key of KGC

Dynamic accumulator

This subsection consolidates the dynamic accumulator background used throughout the protocol. The proposed scheme utilizes an accumulator as a repository for registered entities, converting a set containing numerous identities and public key information into an accumulator value while generating a concise witness to verify that a specific element belongs to the set F^33,34. Dynamic accumulators enable the committee to manage member identities without retaining all member information, thus enhancing the efficiency of the authentication scheme. Compared to schemes lacking dynamic accumulators, this scheme provides considerable advantages in computational efficiency and storage costs.

In this scheme, the dynamic accumulator comprises five functions: , , , , and . The witness generation function, , produces proof for an element using the accumulator value and the set F. The verification function, , assesses the validity of the witness. The addition function, , and the deletion function, , modify the set and accumulator value as elements are added or removed. Additionally, the witness update function, , ensures that the witness for any modified element remains valid, thereby preserving the integrity of the set’s cryptographic proof.

To justify our choice of dynamic accumulators, Table 1 compares DA4FL’s accumulator-based approach with alternative membership data structures (Merkle trees and Bloom filters) in terms of asymptotic complexity, revocability, false positives, and message rounds required for authentication. As shown, dynamic accumulators offer constant-time operations for add, delete, and verify, support true revocability without false positives, and enable efficient three-round authentication. Merkle trees incur logarithmic overhead for updates and verification, while Bloom filters lack true deletion and introduce probabilistic false positives, making them unsuitable for security-critical AKA protocols.

Table 1.

Comparison of membership data structures for AKA.

Scheme	Add	Del	Verify	Revocable	False positive	Message rounds
Dynamic Accumulator				Yes	No	3
Merkle Tree				Yes	No
Bloom Filter				No	Yes	1–2

Threat model

This subsection centralizes the adversary capabilities assumed in our analysis. To the best of our knowledge, the extended Canetti-Krawczyk model (eCK)³⁵ describes an adversary more powerful than those depicted in the Dolev-Yao (DY) model³⁶. Such a formidable adversary model presents significant threats to FL. Consequently, it is essential to incorporate the eCK adversary model when assessing the robustness of the proposed protocol. The eCK model specifies eight capacities that the adversary may possess.

• can intercept, modify, insert, and delete any communication messages in the open channel.

• can polynomially offline enumerate all items in the Cartesian product of ID space and password space .

• To a password-based authentication in the scheme, can compromise the following one factor: (a) the user’s password or (b) data stored in the smart card.

• can get any previous session key of the user.

• can learn the KGC’s secret long-term key when considering the system’s eventual failure.

• can obtain ephemeral secrets when testing the security of the session key.

• can compromise a user to get his/her sensitive data, and subsequently impersonate the compromised user to participate in the next communication among the KGC, task publisher, and other users.

• may be the KGC, only when assessing the security of the user’s password in the registration phase.

Message Authentication Codes (MACs)

We use MACs for lightweight message integrity and authenticity in FL exchanges. Concretely, an entity computes over the timestamp TS, the session key SK, and the message M (e.g., an encrypted model or its hash); the receiver verifies the tag via before acceptance. This aligns with the later “Model upload and Verification” phase and avoids the high cost of digital signatures.

Shamir’s (k, n) threshold secret sharing

We employ Shamir’s (k, n) threshold scheme³⁷ to split the KGC master secret among n independent holders, ensuring that any k shares can reconstruct the secret while fewer than k reveal nothing; the detailed process appears later in Algorithm 1 during System Setup.

Algorithm 1.

Shamir’s (k, n) threshold secret sharing.

Problem statement

Design goals

The goal of DA4FL is to design a secure and efficient AKA protocol for FL. Specifically, the objectives are as follows:

1. Authentication key agreement: DA4FL achieves an anonymous AKA process with mitigated centralized issues, ensuring the semantic security defined formally in 6.1.

2. Protection of local training data integrity: The protocol ensures the integrity of local training data, preventing any unauthorized modifications or tampering during the FL process. Given model, MAC, verification is performed using the function:

   

3. Resistance to known attacks: DA4FL must comprehensively addresses critical security threats including replay attacks, ephemeral secret leakage, impersonation attacks, and man-in-the-middle attacks and achieves forward secrecy. Our security analysis in section “Heuristic analyses” focuses exclusively on attack vectors relevant to federated learning environments.

4. Efficient dynamic membership management: DA4FL must provide efficient member management than static schemes¹⁶, allowing for real-time user additions or removals without needing to reconstruct the entire member list.

System architecture

We introduce the system model of DA4FL in Fig. 2. It comprises five components: the KGC cluster (with multi-KGC architecture and threshold secret sharing), task publishers (initiating and managing FL training), users (local trainers with data privacy), the blockchain committee (decentralized state management and transaction verification), and IPFS (off-chain storage for large model updates).

Fig. 2.

Architecture of DA4FL.

KGC cluster: The KGC Cluster is structured as a dynamic consortium consisting of one active KGC and candidate KGCs. This cluster is responsible for creating the system’s public parameters and generating pseudonyms and secret values for users and task publishers to facilitate anonymous communication. The active KGC is not a permanent entity. Instead, it is randomly selected from the pool of candidate KGCs by a smart contract on the blockchain at system initialization or during a recovery process triggered by the committee. To ensure the security and resilience of the master secret key, it is securely split into n shares using Shamir’s (k, n) threshold secret sharing scheme, and these n shares are distributed among all n members of the consortium, meaning no single member possesses the complete master secret key. Furthermore, to facilitate system recovery, critical user state information is encrypted and stored on the blockchain, ensuring it remains accessible even if the active KGC fails.

Users: Users act as trainers for local models. They acquire local models through training, perform mutual authentication with task publishers, upload model training data to IPFS, and submit upload requests to the blockchain along with a MAC.

Task publishers: Task publishers initiate training requests on the blockchain and negotiate session keys through the authentication process. Once the blockchain validates the reliability of the uploaded models from users, task publishers decrypt the models using the session keys and aggregate them.

Committee: The committee operates a consortium blockchain. It handles transaction submission (training requests and model uploads), verifies senders via the accumulator, caches verified transactions, and discards failed ones. Members can be appointed by a trusted organization or elected via a committee algorithm³⁸ and reach consensus using an appropriate protocol³⁹. If the KGC fails, the committee detects it and triggers recovery through the KGC management smart contract.

Interplanetary File System (IPFS): IPFS is utilized to store uploaded models. Due to the inefficiency and high cost of uploading large files directly to the blockchain, this system involves uploading model training data to IPFS and storing the returned addresses on the blockchain. We use IPFS for mature content-addressed storage and broad gateway/tooling support, keeping large payloads off-chain. Swarm and Filecoin are compatible but add tighter Ethereum coupling (Swarm) or storage-market overhead/latency (Filecoin), so we omit them here; backends are swappable without changing DA4FL’s message flow⁴⁰.

Initially, during the system setup phase, the committee triggers the smart contract to select an active KGC from KGC candidates using a verifiable random function (S-1, S-2). After that, the active KGC generates system parameters and initialize the system. Then, during the registration phase, both users and task publishers register with the active KGC, receiving pseudonyms and secret values while the KGC stores encrypted user states on-chain (R-1, R-2). Subsequently, the user and task publisher authenticate each other through blockchain-verified pseudonyms and negotiate a session key using dynamic accumulators for constant-time membership verification (A-1). Utilizing this session key, the user encrypts model updates and uploads them to IPFS, submitting only the content identifier and MAC to the blockchain (A-2). Following this, the committee verifies the legitimacy of the sender using the accumulator value and the task publisher checks MAC integrity (A-3). Finally, the task publisher retrieves encrypted models from IPFS, decrypts them using the corresponding session keys, and aggregates the models (A-4, A-5).

The proposed protocol

Main idea

The core of our DA4FL protocol is built upon four key design ideas. (i) A hybrid architecture integrates a centralized Key Generation Center (KGC) for efficient registration and pseudonym generation with a decentralized blockchain for tamper-proof state backup and transaction verification. (ii) A (k, n) threshold scheme distributes the KGC’s master secret key to enable verifiable recovery. (iii) A dynamic accumulator enables the blockchain committee to verify membership with constant-time operations, ensuring efficient and scalable management. (iv) Message Authentication Codes (MACs) are used to verify the integrity of encrypted model updates stored off-chain. The protocol encompasses a System Setup Phase, Registration and Authentication Phases for secure participation, a Dynamic Accumulator-based membership management mechanism, a Model Upload and Verification Phase to ensure model integrity, an Update Phase for managing dynamic membership and secret refreshment. This hybrid architecture combines the performance benefits of centralized computation with the fault tolerance and long-term integrity guarantees of decentralization. The meanings of symbols used in the protocol are detailed in Table 2.

System setup phase

The system setup phase establishes the foundational parameters and initializes the blockchain. This process is orchestrated by a KGC cluster, which consists of n candidate KGC nodes, and a blockchain committee. The setup proceeds as follows:

• (i)Blockchain and accumulator initialization: The blockchain committee collaborates to initialize the consortium blockchain. They first generate the initial set F, which includes all committee members and the n candidate KGCs. For each entity k, an element is computed. The committee and the candidate KGCs then cooperate to compute the initial accumulator value , where and m is the number of initial members. This value , along with the set F and a timestamp, forms the genesis block of the blockchain.
• (ii)Active KGC selection: The dedicated KGC management smart contract is first initialized with the list of n candidate KGCs, according to Algorithm 2. Upon initialization, the contract executes the SelectActiveKGC algorithm using on-chain randomness (e.g., the latest block hash) to verifiably select the first active KGC from the candidate pool. This node assumes the role of the active KGC for the initial phase.
• (iii)Parameter generation by the active KGC: The newly selected active KGC performs the following steps to generate the system’s core cryptographic parameters: Key initialization: The active KGC randomly selects a master private key (MSK) and defines the public system parameter (n). Hash function selection: It chooses a secure one-way hash function , sets its identity (), and computes the pseudonymous identifier . Elliptic curve setup: It selects two large primes (p and q) that meet the security parameter (n), generates an elliptic curve over the prime finite field , and chooses a generator P of the q-order additive subgroup G based on . Subsequently, it selects its private key () for the blockchain and generates the corresponding public key (). Parameter publication: The active KGC securely stores and publishes the system public parameters to all participants.
• (iv)Threshold secret sharing and distribution: After generating the MSK, the active KGC applies Shamir’s (k, n) threshold secret sharing scheme⁴¹ to split the master key MSK into n shares. These shares are then securely distributed to all n members of the KGC cluster, ensuring that any subset of k members can reconstruct the MSK, while any subset of fewer than k members gains no information about it. The detailed process is formalized in Algorithm 1.

Algorithm 2.

Verifiable KGC selection with initialization.

Upon completion of these steps, the system is fully initialized, and the active KGC is ready to handle subsequent operations such as user registration and authentication. For the remainder of the protocol description, unless otherwise specified, all references to the “KGC” denote the selected active KGC, who is responsible for managing the day-to-day operations of the system. The other members of the KGC cluster are referred to as candidate KGCs.

Registration phase

First, user locally generates a private-public key pair. randomly selects a 160-bit number as the private key and calculates the corresponding public key . then selects a password and compute . Then, initiates the following registration steps with the KGC.

• (i)Identity selection and initial request: first randomly chooses an identity and sends along with the registration request to the KGC.
• (ii)KGC processing and response: Upon receiving the registration request from , selects a secret number , then computes and computes . KGC stores in list securely. After that, KGC sends to via a secure channel. Then, the KGC computes and upload (, ) to the blockchain. Lastly, KGC puts to the set F and updates the accumulator value to the blockchain.
• (iii)User response and blockchain update: receives . Then randomly selects , calculates and publishes its in blockchain. then securely stores in a smart card.
• (iv)Witness generation: generates an existential witness based on the accumulator value in the blockchain.
• (v)Committee verification and block addition: A committee appends to the most recent block. Other committee members validate through ; if valid, the block is added, and their witness is refreshed in the accumulator. Otherwise, the block is discarded.

The registration of task publisher is similar to ’s. So, it is omitted here.

Authentication phase

The DA4FL authentication involves three message rounds: (1) KGC: user initiates authentication with ; (2) KGC : KGC forwards verified request with ; and (3) : task publisher completes key agreement with .

In this phase, and can share parameters of the model securely after that and authenticate each other. The detailed steps in the authentication phase are shown below. To enhance the understanding of the authentication phase, the scheme’s workflow and detailed cryptographic computation process is illustrated in Fig.  3.

Fig. 3.

Authentication and session key agreement in DA4FL.

• (i)Identity and password verification: User enters their identity and password . The smart card computes , where is the smallest positive integer such that , with O denoting the point at infinity on the elliptic curve. It then retrieves from the blockchain using , selects a random nonce , records the current timestamp TS, and sends the authentication request to the KGC over a public channel.
• (ii)KGC time validation and data retrieval: Upon receiving the authentication request from , verifies the time validity by checking , where is the maximum time threshold for accepting messages, and is the current time. If the time is invalid, discards the request; otherwise, goes to the next step. use to check for and retrieves in the list . Then computes the .
• (iii)Parameter verification and authentication by KGC: checks the validation of . If not, discards the authentication request; otherwise, can authenticate and retrieves in the list through . Finally, sends message to by a public channel with .
• (iv)Time check and data extraction by : Upon receiving the message from KGC, initially checks the validation of time by . If so, extracts from the public channel and calculates .
• (v)Final validation and message transmission by : validates . If the validation fails, denies the communication request. Otherwise, can verify KGC and then proceed with the following steps. extracts newest and and then computes . Then validates if . If not, discards the communication request. Otherwise, chooses a random number and computes and then transmits message to .
• (vi)Completion of authentication by : When obtains the message from , first computes and verifies . If so, can authenticate and establish the common session key . If not, discards the communication request.

Model upload and verification phase

After the authentication process, both and share the same session key SK. Then can encrypt his/her model training data to C, using symmetric encryption algorithms, such as AES. Given that transmitting the local model on the blockchain would significantly increase communication costs, initially stores the encrypted model C on IPFS, and the corresponding transaction includes the IPFS address addr. Specifically, initiates an upload transaction by calculating , where is the hash of the encrypted model C. then publishes the transaction to the blockchain.

To realize a unified workflow that integrates authentication with model transmission, the protocol binds upload immediately to the just-established session. This design mitigates the downsides of sequential decoupling by eliminating a TOCTTOU (Time-of-Check to Time-of-Use) window and preventing re-binding/replay: at upload time the committee verifies membership with and , and the task publisher re-checks the MAC using the same SK. Freshness via and constant-time accumulator verification ensure atomicity with respect to revocation and state changes, while lightweight per-upload session-key updates further reduce exposure without full re-authentication.

Upon receiving transaction , the blockchain committee first verifies the timeliness by checking . The committee then confirms the node’s presence in the Accumulator using . If confirmed, the transaction is added to the block. The task publisher subsequently retrieves the transaction from the blockchain and extracts C from IPFS by addr. They compute and checks if . If they match, the model is accepted; otherwise, it is discarded.

Dynamic update mechanisms

In this update phase, we address the updating of session keys with dynamic update mechanisms, , membership details, and users’ passwords.

Update of session keys

In scenarios where each upload of model training data necessitates a distinct session key, traditional approaches typically entail re-authentication and key agreement, thereby imposing substantial communication overhead. Our method introduces an efficient mechanism for updating session keys after initial authentication, significantly reducing associated communication costs.

Upon successful authentication, both the user and the task publisher securely store their respective values, timed with . During this phase, it is imperative that remains within its effective period to ensure the validity of . Both parties merely need to generate new random values and , subsequently publishing and on the blockchain. Thereafter, they are able to calculate the new session key . For highly sensitive data requiring stringent security, setting to 0 mandates a full re-authentication process instead of utilizing the shortcut for key negotiation and authentication.

Update of PID and secret values

To ensure anonymity and untraceability, may request immediate identity updates from the KGC. Specifically, when updates their identity and secret values with the KGC, both entities adopt new identities and secrets as follows: . Subsequently, the KGC records the relationship between and , and then refreshes the accumulator value using .

Update of membership

Considering the addition of new members, they must adhere to the established registration procedure. For members intending to leave, such as user , a resignation transaction is sent to the blockchain. The Committee then executes to exclude the member from the accumulator set and updates the accumulator value in the subsequent block. Thereafter, the KGC uses the participant’s to locate ’s information and deletes it from the list .

Update of users’ password

can also change his/her password with the following steps:

1. first inputs his/her identity and password , and the smart card will compute: .

2. selects the new password and computes .

3. Then he/she stores in a smart card securely.

Update of active KGC and MSK

The update of MSK begins when a committee member triggers the KGC rotation contract. The contract executes SelectActiveKGC (Algorithm 2) to verifiably elect a new KGC using on-chain randomness.

The newly elected KGC collects the shares from the committee members and reconstructs the previous master secret key MSK. Using MSK, it recovers the hidden state from the on-chain pseudonym and ciphertext pair via:

After that it processes any backlogged registration requests that are still within their valid time window. Then, the KGC generates a new master secret key and re-encrypts the data as:

and uploads to the blockchain. Finally, the new KGC generates and distributes its (k, n) Shamir shares securely to the n committee members.

Upon completion of these steps, the system resumes normal operation with the new active KGC.

Security analyses of the proposed protocol

We analyzed the security and performance of the proposed protocol. The security analysis includes: (1) Provable security, where we demonstrate the semantic security of the session key in this section; (2) Heuristic analysis, which shows that the protocol can resist known attacks. The performance analysis involves the protocol’s functionality, communication and computation, where we compare the proposed DA4FL with three related schemes.

Formal security analysis

In this section, based on the eCK adversarial model, we give a security formal proof that the adversary cannot compromise the semantic security of the session key in our proposed protocol.

Note that the security of our scheme fundamentally relies on two well-known hard problems in elliptic curve cryptography. The first is the Elliptic Curve Discrete Logarithm Problem (ECDLP), which posits that it is computationally infeasible for an adversary to determine the scalar given a point on an elliptic curve and its scalar multiple , even with knowledge of both and ⁴². The second is the Elliptic Curve Computational Diffie-Hellman Problem (ECCDHP), which states that, given two points and , where and are unknown scalars in , it is computationally infeasible for any polynomial-time adversary to derive the shared key with significant probability⁹.

Basics for formal proof

In protocol , there are three participants: the user , the task publisher , and the KGC. Before initiating the simulation, the simulator begins by selecting an elliptic curve over a prime finite field and chooses a generator P from the additive subgroup of order q, where p and q are large prime numbers. The length of q meets . Following this, the user obtains personal information , along with a smart card containing {}. Meanwhile, the active KGC is selected by the smart contract and it generates the master secret key MSK, applies Shamir’s (k, n) threshold secret sharing scheme to split MSK into n shares , and securely distributes each share to n independent KGC candidates, and the task publisher stores information secretly.

In the proof, three entities are instantiated individually as follows: is instantiated as , as , and KGC as . When we want to represent any of them, we can simplify their notation to . Each instance is treated as an oracle, meaning that its state will change from accept, reject, or return “” (indicating no response) depending on whether the input message is valid, invalid, or null.

Following, we provide some terms used in this proof.

. When instance successfully receives the final expected communication in the protocol, it enters an acceptance state. During this session, all transmitted and received messages are sequentially concatenated to generate the session identifier for instance .

. Instances and are regarded as matched when the following conditions achieve that: (a) both are in an acceptance state, (b) they authenticate each other using the identical session identifier.

. The eCK adversary is presumed to interact with the simulator and honest parties via oracle queries. tries to compromise the integrity of authentication messages or the confidentiality of the session key by leveraging the oracle responses. The types of queries that is allowed to perform are outlined below.

• (). In this query, emulates the full authentication procedure and captures the communications of , KGC, and .

• (). Using this query, can transmit message m to instance to initiate an attack, with the simulator replying by protocol .

• (). Through this query, obtains previous session keys from its corresponding partner instance.

• (). This query grants the adversary access to temporary keys, such as nonce values or short-term secret data.

• (). Through this query, can retrieve critical data stored on the user’s smart card.

• (). This query allows to obtain the master secret key MSK along with the private key .

• (). Using this query, can access confidential information belonging to .

. An instance, whether , , or , is considered to be fresh if has not gained access to the session key between and .

(). This query is designed to assess the semantic security of the session key SK, and is allowed to execute this query only once. In the context of protocol , the instance can either represent or . If the instance has already been queried by (), then the query will return “” (null). Otherwise, the oracle will flip a fair coin b. If , () provides the actual session key SK to ; otherwise, it returns a random string with the same length as SK.

. In protocol , a PPT adversary can perform several queries including Execute, Send, Compromise, and Test. aims to guess the outcome of the coin flip b in the Test query and submits its guess . Let represent the probability that correctly guesses . The adversary’s advantage in breaking the semantic security of the session key in protocol is defined as:

Semantic security proof

Following, we give a detailed security proof to indicate the advantage of adversary breaking the session key’s semantic security can be negligible.

Theorem 1

Let represent the proposed protocol, and and represent the probability advantage of a PPT adversary in solving the ECDLP and ECCDHP, respectively. If a PPT adversary carries out Execute, Send, Hash, then the advantage that has in compromising is negligibly:

Proof

In the step-by-step proof, a sequence of games is defined from Game to Game. Let denote the likelihood that successfully guesses the b in Test query in Game, for .

Game: This game models a real-world attack scenario under the random oracle model. A bit b is chosen at the beginning. Therefore:

1

Game: This game introduces a hash table . Whenever makes a hash query , the hash oracle looks for in the table . If the value is already stored, returns it. If not, it creates a random value , and sends it to , and records the pair in .

In this scenario, tries to use the available hash list to issue the Test query, aiming to figure out whether the session key is real or randomly generated. Factually, the session key is derived using secret elements like , , of , , and random numbers and . Without knowledge of these secret components, cannot calculate SK and is left to guess, making it impossible to determine if or with certainty.

As a result, the probability that can succeed in Game by eavesdropping is no greater than its advantage in Game, meaning:

2

Game: In this game, adversary attempts to deceive one of the participants into accepting a fabricated message by issuing multiple Send and Hash queries. Unlike Game and Game, might gain an increased advantage by finding collisions. If the following collision events occur, the game is terminated:

• (i)A collision in the hash outputs, occurring with a probability of , where l represents the bit length of the hash output.
• (ii)Collisions between the random values (, , , ) may occur with a probability of .

Thus, we have:

3

Game: In this game, adversary attempts to guess the values of , , ACK, and without making any hash queries.

It follows that:

4

Game: Here, adversary tries to deduce the value of without issuing any hash queries.

Similarly, we obtain:

5

Game: In this game, adversary executes a lost smart card attack by issuing a () query. With the help of the “fuzzy keyword and honeyword” approach, the probability of guessing the correct user password is no more than , where constants and relate to the ⁴³. In this case, makes up to attempts within the password space . Therefore, we derive:

6

Game: Here, adversary interacts with the oracles () and () to obtain outdated session keys and random values , . Nonetheless, without knowledge of the secrets and , is unable to compute . Alternatively, might attempt to find a hash collision.

Hence, we have:

7

Game: In this scenario, issues a () query to access the task publisher ’s secret values, such as and . Despite successfully compromising , adversary is unable to derive from or from , as solving the ECDLP in polynomial time remains infeasible for .

That is, we can have:

8

Game: In this game, adversary is no longer allowed to use the Execute, Send, or Corrupt queries and instead tries to calculate the session key directly. Since there is no efficient algorithm to solve the ECCDHP, ’s advantage in recomputing to retrieve , denoted as , is negligible.

Therefore, we conclude:

9

At this stage, the probability of successfully guessing the correct session key does not significantly exceed , meaning that .

By equations (1) through (9) and leveraging the triangle inequality, we get

where

In conclusion, adversary does not hold a significant advantage in breaking the semantic security of session key SK. The advantage is bounded by the following expression: to break the semantic security of SK, where .

Heuristic analyses

This section offers a comprehensive analysis of the proposed scheme’s security features, which include mutual authentication, session key establishment, and forward secrecy. Additionally, it illustrates the scheme’s efficacy in mitigating various attacks, such as replay attacks, password guessing, and man-in-the-middle attacks. We also executed simulations for four representative attacks–replay, impersonation, man-in-the-middle (MITM), and ephemeral secret leakage (ESL)–and observed fast rejection in all cases: replay 0.068 ms (± 0.017), impersonation 0.249 ms (± 0.039), MITM 0.495 ms (± 0.010), and ESL 1.797 ms (± 0.037). Note that the experiments were conducted on a virtualized computing environment based on an AMD EPYC 9754 128-Core Processor. The virtual machine allocated for the experiments provided 8 CPU cores and 16 GB of RAM, running on Ubuntu 24.04.2 LTS.

Mutual authentication

Mutual authentication is the process where two parties verify each other’s identities. In the proposed DA4FL, the KGC authenticates by verifying . Meanwhile, authenticates the KGC by verifying and authenticates by verifying . Additionally, authenticates by verifying , thereby achieving mutual authentication.

Session key establishment

The session key agreement ensures that no party can compute the session key on its own or predict it in advance without cooperation from others. Factually, the session key relies on contributions from ’s (, , ) and ’s (, , ), ensuring that neither , KGC, nor can independently derive the session key.

Conditional privacy protection

Conditional privacy protection ensures that under normal circumstances, user privacy is maintained through anonymity and identity protection. However, in the event of malicious activity, the KGC can trace and reveal the true identity of the user. The KGC assigns pseudonyms to each node for transactions, where MSK is divided into n shares and distributed among multiple independent committee nodes using Shamir’s (k, n) threshold secret sharing scheme. To uncover true identities, an adversary would need to compromise at least k out of n committee nodes to reconstruct MSK, which is considered practically infeasible. This ensures effective privacy protection. Each pseudonym is valid for a specific authentication, and after completing an upload operation, the pseudonym will be a new pseudonym . Linking and requires simultaneous access to , , and , ensuring that pseudonyms from the same source remain unlinked.

Forward secrecy

Forward secrecy ensures that, even if long-term secrets such as the KGC x and MSK are compromised, previous session keys remain secure. Consider a scenario where an adversary knows x, MSK, , , and . Despite this knowledge, given the complexity of the ECCDHP, the adversary cannot compute to derive the session key SK, thereby preserving the protocol’s forward secrecy.

Data integrity of model updates

Data integrity means that the task publisher accepts only the exact ciphertext bytes produced by the authenticated client within the current freshness window. To forge a model update, an adversary must produce a valid on-chain message . However, the adversary cannot forge the MAC, because the message authentication code is computed as , which requires the session key SK. Therefore, data integrity is preserved.

Password guessing attacks

As defined in⁴⁴, password-guessing attacks can be classified into two categories: those targeting validation data stored in the smart card (Attack I) and those exploiting verification data transmitted over a public channel (Attack II). In Attack I, the smart card stores only password-related values such as , which leaves no accessible verification data for attackers to exploit. In Attack II, the password verification process relies on ACK. Even if attackers acquire and retrieve ACK by accessing the smart card, they cannot verify guessed passwords or identities ( or ) because the modular operations in ensure security.

Replay attacks

Replay attacks involve an attacker attempting to resend old messages to pass verification. However, in each session, and generate new random values, or , ensuring the uniqueness and freshness of the messages. Consequently, the attacker cannot reuse previous messages or compute the session key to bypass ’s verification.

Man-in-the-Middle (MITM) attack

In a Man-in-the-Middle (MITM) attack, an adversary intercepts the communications between the user and , capturing the messages sent by the user and the responses from . The adversary may attempt to forge a new set of messages or replay old ones. However, they are unable to convince or that they hold the secret values , , or the private keys and . Consequently, the attacker fails to pass the authentication process, effectively preventing the MITM attack.

Ephemeral secret leakage (ESL) attack

This type of attack, also known as a transient key leakage attack^35,45, occurs when an attacker attempts to derive the session key by intercepting temporary session data, such as the random values and . In our proposed DA4FL, the session key SK is produced by combining both short-term random values and long-term secret data, including and . Consequently, even if an attacker obtains and , they cannot compute the session key SK, rendering the attack ineffective (Table 4).

Table 4.

Security functionalities comparisons of all related authentication schemes.

Schemes	Year	Criteria
		I	I	I	I	I	S	S	S	S	S
Huang et al.9	2024
He et al.46	2023
Fan et al.10	2023										—
Parameswarath et al.15	2022	—				—		—			—
Srinivas et al.47	2020
DA34FL	—

Impersonation attack

For an external malicious node, lacking the private key and long-term secret values of a legitimate node, it cannot impersonate a legitimate entity to communicate with the KGC. For a legitimate user, computing the private key and long-term secret values of the KGC during the session key negotiation process is infeasible due to the ECDLP, thereby preventing impersonation of the KGC.

Experiments and performance analyses

In this section, we present a comprehensive performance analysis, including functionality comparisons and cost estimation comparisons among five state-of-the-art (SOTA) user authentication protocols. Note that the experiments were conducted on a virtualized computing environment based on an AMD EPYC 9754 128-Core Processor. The virtual machine allocated for the experiments provided 8 CPU cores and 16 GB of RAM, running on Ubuntu 24.04.2 LTS.

Functionality analysis

To evaluate the strengths and weaknesses in terms of functionality, the widely recognized 10 criteria⁴⁸ were employed. These criteria comprise five ideal attributes (I) and five security attributes (S), as detailed in Table 3. In terms of ideal attributes, the DA4FL outperforms existing schemes in several key areas. For password friendliness (), unlike Fan et al.’s scheme which does not permit users to modify their passwords locally¹⁰, both Huang et al. and the proposed protocol support this feature⁹. Additionally, He et al.’s scheme⁴⁶ also supports local password modification, but Srinivas et al.’s scheme⁴⁷ enhances this by integrating robust password management mechanisms without compromising usability. Regarding key agreement (), Parameswarath et al.’s scheme¹⁵ lacks the capability to establish a session key, and He et al.’s scheme⁴⁶ does not provide mutual authentication (), potentially limiting its practicality in certain contexts. All schemes except Parameswarath et al.’s¹⁵ offer mutual authentication (). Furthermore, Parameswarath et al.’s use of a password verifier table () poses a risk of password leakage¹⁵, while He et al.’s scheme⁴⁶ does not fully safeguard mutual authentication, leaving it susceptible to specific attacks.

Table 3.

10 Criteria for evaluating authentication schemes.

Category	ID	Criteria	Definition
Ideal attributes	I	Password friendly	Users can freely select and locally modify their passwords
	I	Sound repairability	Users can join dynamically, and smart card can be revoked
	I	Key agreement	Users and task publishers must establish a session key after authentication
	I	Mutual authentication	All parties should authenticate each other’s identities
	I	No password verifier table	Only users store their password-related data
Security attributes	S	User anonymity	Adversaries cannot deduce or track users’ identities
	S	No password exposure	Privileged participants (e.g., KGC administrators) cannot access user passwords during registration
	S	Forward secrecy	Even if KGC’s long-term key is compromised, the session key remains secure
	S	Resistance to known attacks	The protocol withstands impersonation, MITM, replay, stolen verifier, and DoS attacks
	S	Resistance to smart card loss attack	The protocol remains secure even if a smart card is lost

In terms of security attributes, the proposed protocol, along with other schemes, ensures user anonymity (), preventing adversaries from identifying or tracking users. Regarding password exposure (), schemes by Huang et al.⁹, Fan et al.¹⁰, and the proposed protocol prevent administrators from accessing users’ passwords during registration, a feature missing in Parameswarath et al.’s scheme¹⁵. However, He et al.’s scheme⁴⁶ fails to adequately protect against password exposure during registration. The proposed protocol also supports forward secrecy (), safeguarding past session keys even if the long-term key is compromised, a feature absent in the schemes of Parameswarath et al. and Srinivas et al.^15,47. Regarding resilience to known attacks (), Huang et al.’s scheme⁹ cannot defend against impersonation attacks, nor can Parameswarath et al.’s and Srinivas et al.’s schemes^15,47 defend against ESL attacks. For , He et al.’s scheme⁴⁶ cannot effectively resist the smart card loss attacks. In contrast, the proposed DA4FL protocol effectively addresses these vulnerabilities, providing robust protection against known attacks.

Cost analysis

In this subsection, we conduct a performance analysis comparing communication and computation costs to demonstrate the efficiency of the proposed DA4FL. To assess communication costs, the lengths of each parameter are detailed in Table 6. Table 5 presents a comparison of communication costs across all evaluated schemes. The proposed DA4FL achieves a total communication cost of 2164 bits, approximately 72.5% lower than that of Parameswarath et al.¹⁵, indicating a significant enhancement in communication efficiency. Although our communication cost is higher than that of Fan et al.’s¹⁰ and Huang et al.’s⁹ schemes, the DA4FL offers improved security features. Notably, our protocol introduces an efficient method to update session keys without completing the entire authentication process, reducing the average cost to levels comparable to the aforementioned schemes.

Table 6.

The length of all terms.

Symbols	Bits	Symbols	Bits
module ()	32	time stamp (t)	32
ECC point (p)	256	random/nonce (r, d)	160
hash value (h)	160	user’s ID (ID)	128
public key (PK)	512	private key (x)	256
password (PW)	160	secret value (s, S)	160

Table 5.

Comparisons of computation and communication costs among authentication protocols.

Schemes	Year	Computational cost			Total communication cost : bits
		User	Task publisher	KGC
9	2024			—	800
46	2023			—	1782
10	2023			—	1472
15	2022				7872
47	2020				2656
DA4FL	—				2164

Compared to He et al.’s scheme⁴⁶, the DA4FL incurs a slightly higher communication cost (2164 bits versus 1782 bits). However, He et al.’s scheme lacks essential security features such as user anonymity (S) and resistance to known attacks (S), making it less suitable for secure FL environments. Srinivas et al.’s scheme⁴⁷, with a communication cost of 2656 bits–approximately 22.8% higher than our protocol–also falls short in computational efficiency and security robustness, lacking features like forward secrecy (S) and resistance to smart card loss attacks (S). Our protocol effectively balances the increased communication cost with stronger security, ensuring robust protection against potential attacks in FL settings.

As shown in Tables 7 and 8, DA4FL incurs a total computational cost of 0.653 ms. This represents a 7.0% reduction compared to He et al.’s scheme (0.702 ms)⁴⁶ and is approximately 29.0% faster than the protocol of Srinivas et al. (0.920 ms)⁴⁷, thereby demonstrating superior efficiency in latency-sensitive federated learning scenarios. Although our cost exceeds those reported by Parameswarath et al. (0.593 ms)¹⁵, Huang et al. (0.316 ms)⁹, and Fan et al. (0.276 ms)¹⁰, respectively–DA4FL compensates for this modest overhead by integrating additional lightweight cryptographic operations and enabling session-key updates without full re-authentication, thereby enhancing overall security and robustness.

Table 7.

Running time of different cryptographic operations.

Symbol	Description	Time (ms)
	256-bit ECC scalar point multiplication	0.065
	Biometric-fuzzy extractor	0.065
	Hash Operation Time	0.004
	Group Signature Generation Time	0.445
	Group Signature Verification Time	0.042

Table 8.

Comparison of total computational costs per authentication for different schemes.

Authentication schemes	Total computational cost (ms)
Huang et al.9	0.316
He et al.46	0.702
Fan et al.10	0.276
Parameswarath et al.15	0.593
Srinivas et al.47	0.920
DA4FL	0.653

In summary, DA4FL achieves a favorable trade-off between performance and security, rendering it suitable for resource-constrained federated learning environments. By delivering lower latency than the schemes of He et al. and Srinivas et al. ⁴⁷, while providing more comprehensive security features than the faster yet less feature-rich protocols of Huang et al. ⁹, Fan et al. ¹⁰, and Parameswarath et al. ¹⁵, DA4FL offers a practical and secure authentication solution for federated learning.

Dynamic accumulator performance evaluation

We conducted a comprehensive performance evaluation of our dynamic accumulator under varying system scales. Specifically, we measured both the latency of three fundamental operations (member addition, witness creation, and membership verification) and the peak memory consumption during accumulator operations, while scaling the number of users from 100 to 10,000. Each measurement was repeated 50 times to ensure statistical significance, and we report both the average and standard deviation in Table 9.

Table 9.

Dynamic accumulator performance metrics with different user counts.

Users	Add (ms/u)	Witness creation (ms)	Membership verification (ms)	Peak memory (KB)
100	12.29 (± 6.75)	33.09 (± 6.34)	11.49 (± 6.34)	27.11 (± 10.43)
500	12.18 (± 7.36)	33.74 (± 9.72)	11.97 (± 9.75)	64.22 (± 0.02)
1,000	12.30 (± 7.61)	33.05 (± 6.81)	11.34 (± 6.83)	88.08 (± 0.02)
2,000	12.23 (± 7.63)	32.82 (± 5.47)	11.68 (± 5.46)	231.88 (± 0.02)
5,000	12.11 (± 7.39)	34.28 (± 8.51)	12.85 (± 8.50)	877.22 (± 0.02)
10,000	12.16 (± 7.35)	33.27 (± 5.96)	11.62 (± 5.94)	998.59 (± 0.02)

As shown in Table 9, the dynamic accumulator demonstrates excellent scalability and efficiency across both computational and memory dimensions. From a latency perspective, the average time for adding a new member remains consistently stable in the range of 12.1–12.3 ms per user, with minimal fluctuations. This demonstrates nearly linear performance even as the number of users increases from 100 to 10,000. The witness creation latency remains stable around 32–35 ms, with only minor variations, and does not show any significant increase as the number of nodes grows. Similarly, the membership verification latency consistently stays within the range of 11–13 ms, with standard deviations generally within acceptable bounds, indicating consistently efficient verification operations.

From a memory perspective, the memory utilization grows sub-linearly with respect to the number of members, remaining under 1,000 KB even at 10,000 users. This demonstrates exceptional memory efficiency, as the accumulator maintains a compact cryptographic representation of the entire membership set without storing individual member records. The extremely low variance across iterations (on the order of 0.02 KB for most scales) indicates highly stable and predictable memory behavior.

Overall, these performance metrics validate the time complexity of the system’s core cryptographic operations and demonstrate minimal storage overhead. Even under dynamic stress tests with user counts scaling up to 10,000, the system maintains low and stable latency with sub-linear memory growth. This confirms that DA4FL is well-suited for resource-constrained environments and large-scale federated learning deployments, where frequent participant changes and efficient membership management are critical requirements.

Implementation

For practical deployment, use widely supported 128-bit security defaults (ECC P-256, SHA-256 as the hash h, HMAC-SHA-256 for MACs, and AES-CTR for encrypting the model ciphertext C with random IVs using an encrypt-then-MAC construction), keep a tight but realistic timestamp window ( 1–5 minutes with clock sync), pin IPFS content across multiple nodes, and choose Shamir’s threshold (k, n) by balancing collusion resistance and availability: pick k so that , where f is the maximum tolerated number of compromised custodians and u the maximum expected offline custodians; in practice, for , for , and for offer balanced trade-offs, while larger k (e.g., ) hardens security at the cost of a higher recovery quorum.

Integration with mainstream FL frameworks (e.g., TensorFlow Federated and PySyft) is straightforward because DA4FL sits beneath the learning logic as a thin authentication layer. Clients run the AKA handshake once per training session to derive SK, then attach to each update a message containing –where C is the ciphertext of the serialized model delta, TS enforces bounded freshness, provides conditional anonymity, and binds integrity to the ciphertext. The client-side hook executes before serialization/transmission (hashing, encryption, and MAC computation); the aggregator-side hook executes on receipt (timestamp check, MAC verification, accumulator membership verification when enabled), and only then decrypts before handing the plaintext update to the framework’s standard aggregator. In practice this can be implemented as gRPC/HTTP middleware or message pre/post-processors, wrapping client-update RPCs in TensorFlow Federated and tensor/state send/receive paths in PySyft, without changing model formats, optimizers, or aggregation code; DA4FL treats updates as opaque bytes.

Conclusion and future work

AKA is crucial for FL, as it prevents unauthorized data leakage and enhances data security. To overcome the limitations of existing AKA technologies, we introduces a robust DA4FL protocol utilizing blockchain, Message Authentication Code (MAC), and dynamic accumulator technologies. The DA4FL design ensures identity verification within FL, as well as the security and integrity of messages, and facilitates dynamic and efficient membership management. Security analysis confirms that DA4FL is robust against the attack vectors analyzed in this work and secures session keys. Performance analysis demonstrates that DA4FL strikes an optimal balance between security and performance, making it well-suited for FL environments. Following, future work will focus on exploring the application of DA4FL in more complex FL scenarios, such as mobile FL environments. Additionally, we plan to investigate the integration of emerging technologies, such as homomorphic encryption and differential privacy, to further enhance the security and privacy of DA4FL in FL applications. While the present ECC and symmetric-based instantiation is not quantum-resistant, future work will explore quantum-resilient techniques such as quantum-resilient accumulators to provide end-to-end PQ security.

Author contributions

Conceptualization, S.L. and K.F.; methodology, S.L.; validation, S.L., Y.Z. and J.B.; formal analysis, S.L.; investigation, S.L., Y.Z. and J.B.; resources, K.F.; writing—original draft preparation, S.L.; writing—review and editing, Y.Z., J.B. and K.F.; visualization, S.L.; supervision, K.F.; project administration, K.F. All authors have read and agreed to the published version of the manuscript.

Funding

This research received no specific grant from any funding agency in the public, commercial, or not-for-profit sectors. All authors declare no financial or non-financial conflicts of interest related to this work.

Data availability

No datasets were generated or analysed during the current study.

Competing interests

The authors declare no competing interests.