RFLPA: A Robust Federated Learning Framework against Poisoning Attacks with Secure Aggregation

Federated learning (FL) allows multiple devices to train a model collaboratively without sharing their data. Despite its benefits, FL is vulnerable to privacy leakage and poisoning attacks. To address the privacy concern, secure aggregation (SecAgg) is often used to obtain the aggregation of gradients on sever without inspecting individual user updates. Unfortunately, existing defense strategies against poisoning attacks rely on the analysis of local updates in plaintext, making them incompatible with SecAgg. To reconcile the conflicts, we propose a robust federated learning framework against poisoning attacks (RFLPA) based on SecAgg protocol. Our framework computes the cosine similarity between local updates and server updates to conduct robust aggregation. Furthermore, we leverage verifiable packed Shamir secret sharing to achieve reduced communication cost of $O(M+N)$ per user, and design a novel dot product aggregation algorithm to resolve the issue of increased information leakage. Our experimental results show that RFLPA significantly reduces communication and computation overhead by over $75\%$ compared to the state-of-the-art secret sharing method, BREA, while maintaining competitive accuracy.

Paper

References (57)

Scroll for more · 38 remaining

Similar papers

Peer review

Reviewer VWie5/10 · confidence 4/52024-07-03

Summary

The paper proposes RFLPA, which deploys a robustness algorithm based on cosine similarity detection on SecAgg, defending against privacy attacks from the server and poisoning attacks from clients. Furthermore, the paper reduces communication and computation costs through packed Shamir secret sharing and dot-product aggregation.

Strengths

1.The structure of the paper is clear, providing a comprehensive and detailed explanation of how RFLPA deploys FLTrust's cosine similarity detection scheme on SecAgg and reduces SecAgg's overhead through packed Shamir secret sharing and dot-product aggregation. 2.Experiments show that, compared to the previous work BREA, RFLPA reduces communication and computation costs by 75% while maintaining the same accuracy. 3.The paper also provides a systematic theoretical analysis and proof of RFLPA's convergence and the cryptographic protocols used.

Weaknesses

1. The paper seems to achieve practical improvements over BREA mainly by reducing communication costs, but the phase of computing cosine similarity among clients introduces additional communication costs. The advantages over other state-of-the-art MPC-based solution ELSA[1], HE & ZKP-based solution RoFL[2], and Blockchain-based solution PBFL[3] are not explained in detail in the paper. 2. Regarding Byzantine robustness, the paper adopts the FLTrust approach, assuming the server holds clean root dataset. However, this requires a substantial number of clean public samples of all labels, making this assumption impractical in real-world scenarios, which is conflicted to the goal of practical PPFL solution. 3. The RFLPA framework seems like questionable.As descripted in section 3.2, the security goal is to defend passive inference and active inference attacks both. But the packed secret shares of $g_i$ generted by client i are sent to the server and the server transmit them to the other clients using a broadcast channel. Which means that the server have all shares of the secret $g_i$ and can recover it. So, what kind of role is played by the server? 4. In the experimental section, a) the robustness testing of BREA only includes two types of Byzantine attacks. The paper lacks strong experiments to demonstrate how BREA performs under more subtle attacks like Krum-attack and Badnet. b) The communication overhead of RFLPA could not be small, because all clients are involved all computation of consin similarity $s^j_k$ of any user pair (i,j), the author should give out the detail results. 6. The notations and formulations should be more clear. a) Line95, $D$ is not predefined. b) Line210, $\tilde{\mathbf{g}}_i$ should be $\bar{\mathbf{g}_i}$. [1] Rathee, Mayank, et al. "Elsa: Secure aggregation for federated learning with malicious actors." 2023 IEEE Symposium on Security and Privacy (SP). IEEE, 2023. [2] Lycklama, Hidde, et al. "Rofl: Robustness of secure federated learning." 2023 IEEE Symposium on Security and Privacy (SP). IEEE, 2023. [3] Miao, Yinbin, et al. "Privacy-preserving Byzantine-robust federated learning via blockchain systems." IEEE Transactions on Information Forensics and Security 17 (2022): 2848-2861. [4] Hao, Meng, et al. "Efficient, private and robust federated learning." Proceedings of the 37th Annual Computer Security Applications Conference. 2021.

Questions

see the above

Rating

5

Confidence

4

Soundness

3

Presentation

3

Contribution

2

Limitations

no

Authorsrebuttal2024-08-11

Dear Reviewer, We are grateful for your constructive feedback. We are happy for your recongnition in the *comprehensive and detailed explanation, effectiveness, and systematic theoretical analysis* of our paper. Below we summarize the main concerns we addressed in the rebuttal: **Additional communication cost of cosine similarity computation**: We provide detailed analysis for the communication cost in each stage. We show that the additional communication cost introduced by cosine similarity computation is small compared to the communication overhead reduced by our approach. **Advantages over other solutions**: We summarize the advantage of our solution over the provided baseline in terms of three dimensions: collusion threshold, robust aggregation rule, and computation overhead. **Assumption on clean public samples**: We clarify that the required clean root dataset could be of small size and slightly diversed from the from the overall training data distribution. We also propose several remedies suppose we cannot get any clean root dataset even if the required size is small. **The server have all shares of the secret and can recover it**: We clarify that the secret shares are encrypted sending to the server and explain the encryption process. **Experiments on subtle attacks**: We conduct additional experiments against KRUM attack, BadNets, and scaling attacks and will include the results in our paper. Once more, we thank the Reviewer for the constructive feedback. We sincerely hope that the provided answers address the Reviewer's concerns and that the score can be reconsidered. Best Regards, Authors of Submission 11258

Reviewer VWie2024-08-13

Considering the higher scores given by other reviewers, I reread the paper and the rebuttal, and still have serval big questions. 1. The algorithm part is hard to follow because the symbolic representation is confusing. Maybe you can clarify some cases of them here. $\langle \mathbf{g_i} \rangle$ denotes the secret sharing of $\mathbf{g_i}$. So $\mathbf{V}^i=\{v_{jk}^i\}$ is also the secret sharing of $\mathbf{g_i}$? In the Algorithm 3 RobustSecAgg, $\{s_{ij} \}$ is the packed secrets of $\mathbf{g_i}$, and $\{v_{ij} \}$ is the witness. And again,$cs_k^j$ denotes the $j^{th}$ share of the cosine similarity between $\mathbf{g_k}$ with $\mathbf{g_0}$? Here $k$ denotes the index of clients, and then in the next part “Step 1: Secret resharing of partial dot product”, $s_{jk}^i$ denotes the share sent to user $j$ for the $k^{th}$ group of elements. Here ,$k$ denote the index of group of elements. Maybe fixing the notations can help the readers. And another, $\ell$ is the number of elements packed into one polynomial, also in the “Step 1: Secret resharing of partial dot product”, $p$ is used for the number of secrets packed. It's very hard to follow your algorithm for me. 2. Efficiency of RFLPA . The design goals include efficiency that mainly is achieved by packed secret sharing. But As we can see, the clients are burdened with a large number of computational tasks. That includes secret sharing, encryption and decryption of shares, addition, scale multiply and multiply on packed secret sharing. IMPORTANT: The multiply on packed secret sharing will generate a degree-$(d_1+d_2) or (2d)$ results and more operations need to be done to keep a degree-$d$ style. That is the main source of communication cost for MPC operation and this paper didn't discuss it. You mentioned “ELSA and PBFL and SecureFL rely on the unrealistic assumption of two non-colluding parties”, RFLPA just put those computation tasks on the clients, maybe that is more unfriendly for the clients (mobile or other edge devices). Existed works can be extended to multi-parties using shamir secret sharing. And this paper didn’t conduct experimental comparison under WAN/LAN setting. 4 round communications per iteration (that did not include the communication incurred by multiply on packed secret sharing also), that would a huge burden for WAN.

Authorsrebuttal2024-08-14

Reply to Reviewer's Comment

Dear Reviewer VWie, Thank you for your reply and time. Hope our response below could address your additional concern. **Q1: The algorithm part is hard to follow because the symbolic representation is confusing.** Thanks for your comment. We apologize for some notation inconsistencies in Algorithm 3. The secret shares of $g_i$ should be $\mathbf{V}_i=v_{jk}^i=\mathbf{v}_{ij}$, and the witness is given by $w_{jk}^i=\mathbf{w}_{ij}$. We will fix the corresponding sentences in Algorithm 3 as followed: - Generate packed secrets $\{\mathbf{v}_{ij}\}_{j\in \mathcal{U}_0}$, commitments $\mathcal{C}$ and witness $\{\mathbf{w}_{ij}\}_{j\in \mathcal{U}_0}$ for $\mathbf{g}_i$ - Recover $(\{\mathbf{v}_{ji}\}_{j\in \mathcal{U}_1\backslash i}, \{\mathbf{w}_{ji}\}_{j\in \mathcal{U}_1\backslash i})=\mathbf{Dec}(\mathbf{c}_{ji},k_{ji})$, and verify the secret shares $\{\mathbf{v}_{ji}\}_{j\in \mathcal{U}_1\backslash i}$ The reviewer's understanding of $cs_k^j$ is correct. To avoid the confusion in index $k$, we will fix the notation in Table 3 and Section 4.5 (line 210 to 214) as followed: $cs_k^j$ -> $cs_j^i$, and $nr_k^j$ -> $nr_j^i$. In that way, $cs_j^i$ would denote the $i^{th}$ share of the cosine similarity between $\mathbf{g}_j$ and $\mathbf{g}_0$. For the interpretation of $l$ and $p$, we have their description in Table 3. In particular, $l$ denotes the number of secrets packed at a polynomial for gradient, and $p$ denotes the number of secrets packed at a polynomial for shares of partial dot product. We sincerely hope that the above clarification and fixing the notation issue could help undertand further details in the algorithm. **Q2: Efficiency of RFLPA** *Q2-a: The clients are burdened with a large number of computational tasks* **Analysis of client's computation cost**: Referring to Appendix H, we have provided stage-wise computation analysis in detail. We also summarize the computation cost for those operations the reviewer mentioned in Table R1. [**Table R1.** Break down of per-user communication cost. Cosine similarity computation incurred O(N) additional communication cost, lower than the original scale of O(M+N).] |Stage|Communication cost| |-|-| |Create packed secret shares|$O((M+N)\log^2 N)$| |Encryption and decryption of shares|$O(M+N)$| |Compute shares of partial dot product (addition and multiply on packed secret sharing)|$O(M+N)$| |Create packed secret shares of partial dot product|$O(N \log^2 N)$| |Derive final secret shares of dot product (addition, scale multiply and decoding)|$O(N^2\log^2 N)$| Therefore, the clients' computation cost is $O((M+N^2)\log^2 N)$. **Improvement in computation time**: It's important to note that our framework focus on improving the efficiency over existing solutions that combines SecAgg with defense strategies against poisonous attacks. RFLPA significantly reduces the total computation cost compared with: (1) HE-based solutions, and (2) BREA that leverages secret sharing method, as demonstrated by our empirical analysis. This is a substantial improvement in the research field that integrate privacy and robustness. **Friendly adaption to device with low computation power**: As we will discuss later in *Q2-c*, our framework can be easily adapted to reduce the computation cost for clients with low resources, such as mobile devices. In that case, the low resource clients only need to generate secret shares, and the subsequent operations will be done by the high resource clients. *Q2-b: The multiply on packed secret sharing will generate a degree-2d results and more operations need to be done to keep a degree-d style.* In RFLPA, there's no need to conduct further operations on the degree-2d results since **Dot Product Aggregation inherently converts the degree-2d partial dot product shares into degree-d final product shares**. After computing the partial shares of dot products, each $cs_j^i$ (or $nr_j^i$) is a degree-2d share vector. During the Dot Product Aggregation, we conduct secret resharing and local computation on the shares. Referring to Appendix G Explanation of Secret Re-sharing, $Chop_d$ matrix is leveraged to obtain a degree-d share vector $\mathbf{h}_k^i$ of the final dot product. We will emphasize this point in our paper.

Authorsrebuttal2024-08-14

Reply to Reviewer's Comment (Continued)

*Q2-c: You mentioned "ELSA and PBFL and SecureFL rely on the unrealistic assumption of two non-colluding parties", RFLPA just put those computation tasks on the clients, maybe that is more unfriendly for the clients (mobile or other edge devices). Existed works can be extended to multi-parties using shamir secret sharing.* Firstly, extending existing works (ELSA, PBFL, and SecureFL) to multi-parties requires significant changes on the algorithm, and that should be another solution/direction to be explored. Furthermore, **our framework can be easily adapted to the case considering the heterogeneous computation power of each client**. For example, the server can select the clients with more computation power to participate in the round 2 & 3 & 4. In that way, clients with weaker computing power could merely generate the secret shares of their local gradients and upload them to the server. This can be achieved by simply limiting the participating client in round 2 & 3 & 4 to the computation powerful clients, thereby improving the user experience for edge devices with low computation power. *Q2-d: Experimental comparison under WAN/LAN setting* Firstly, **performing experiment under WAN/LAN setting is unnecessary since the communication time is mainly determined by the message size**. In WAN, the extra communication time for multiple rounds of communication mainly comes from latency, i.e., the time it takes for a message to travel from the sender to the receiver. The latency is negligible compared to the time it takes to transfer the message. Specifically, the latency in WAN setting ranges from 20ms to 700ms (within 1 seconds) depending on the geographical distance. On the other hand, the time to transfer the message (ignoring latency in WAN setting) is around 6.4 seconds for RFLPA, and 52 seconds for BREA, assuming 100 clients using a 1.6MB classifier and 100 Mbps per client. Therefore, the latency from multiple communication rounds is much smaller than the time RFLPA reduced for smaller message size. Furthermore, many existing SecAgg algorithms (focusing only on privacy protection) also rely on multiple communication rounds. For instance, [1] and [2] leverages 4 communication rounds per iteration. Our framework is able to integrate defense against poisoning attack into SecAgg using the same communication rounds as [1] and [2]. Overall, we sincerely hope that our explanations could address the reviewer's further concerns. [1] Bonawitz, K., Ivanov, V., Kreuter, B., Marcedone, A., McMahan, H. B., Patel, S., ... & Seth, K. (2017, October). Practical secure aggregation for privacy-preserving machine learning. In proceedings of the 2017 ACM SIGSAC Conference on Computer and Communications Security (pp. 1175-1191). [2] Bell, J. H., Bonawitz, K. A., Gascón, A., Lepoint, T., & Raykova, M. (2020, October). Secure single-server aggregation with (poly) logarithmic overhead. In Proceedings of the 2020 ACM SIGSAC Conference on Computer and Communications Security (pp. 1253-1269).

Reviewer VWie2024-08-14

*About Q2-a*: Secret sharing-based operations cost the network resources, the encryption and decryption of shares consume the computation resource, that cannot be treated as same. So RFLPA replaces the p2p channel between clients assumed in BERA by using the sever as a repeater(or forwarder) with encryption of the shares. So the encryption/decryption cost will be introduced to the clients. *About Q2-b*: I guess that you use a method like the degree-reduction technology in shamir secret sharing? Every $p$ elements in $cs^i$ is reshared as a degree-d polynomial. So the communication cost is genereated by the resharing operation. Maybe that has been included in " (3) sending and receiving secret shares of partial gradient norm square and cosine similarity (O(N) messages)"? So using a packed secret sharing with the partial dot product is the core contribution of this paper, and I encourage the authors to improve the representation of the key part. It's not very clear for me, and it's important to understand your work for the researchers in MPC/PPML.

Reviewer VWie2024-08-14

*About Q2-c*: Adaption to heterogeneous computation power of each client is a good idea. But I must point out that selecting clients with more computation power by the server will increase the risk of collusion attack among the server and the clients. If we consider that the server could collude with some clients, the privacy goal of RFLPA will be failed. *About Q2-d*: Communication round is a very important factor under WAN setting that you shouldn't ignore. For example, if you have 1000 rounds communication, and the latency will increase 1000*100ms(assume the latency will be 100ms for WAN and ignored for LAN) = 100s, that is also the main cost for the secret sharing-based solutions compare with those based on HE(heavy computation) or Garbled Circuit (heavy communication bytes). You mentioned that "many existing SecAgg algorithms (focusing only on privacy protection) also rely on multiple communication rounds"[1][2]. Those works use Diffie-Hellman for key negotiation, and their multiple rounds of communication occured in **offline phase**.

Authorsrebuttal2024-08-14

Reply to Reviewer's Comment

Dear Reviewer VWie, Thank you for your reply and time. Hope our response below could address your additional concern. **Reply to Q2-a:** Firstly, the encryption and decryption is based on symmetric encryption, much more efficient than the assymetric encryption in HE-based protocol. During our experiment, we found that the encryption & decryption time on the secret is much smaller than the time for other operations on the secret shares, including secret sharing and reconstruction. Furthermore, even if in the BREA's p2p channel, the symmetric encryption on the secret shares is neccessary to avoid the ear dropper's inference attack. However, their solution omit this encryption & decryption process, posing the user's private value in great risk. The encryption is indispensable for secure communication. **Reply Q2-b:** The dot product aggregation protocol shares some relation to the degree reduction protocol in terms of secret resharing. The degree reduction is included in (3) sending and receiving secret shares of partial gradient norm square and cosine similarity (O(N) messages). We are pleased that the reviewer recognize the value and contribution of our *packed secret sharing with dot product aggregation* protocol. The major purpose of dot product aggregation is to address the issue of increased privacy leakage, and we believe that this benefit (in terms of privacy) has been clearly understood and recognized by the readers and reviewers. The degree reduction can be treated as the side benefit (though not the major purpose), and we will highlight this point in our paper. **Reply to Q2-c:** We understand that the inherent tradeoff between the number of participating clients and collusion threshold. At the same time, we would like to make it clear that: - Even if we select a proportion of clients, the privacy risk is much lower than the case in HE's 2 non-colluding parties. - Even if we use the whole set of clients, each client's computation cost is significantly lower than the protocol proposed by BREA with $O(n)$ threshold. - In cross-silo setting, the clients typically host stronger computing power (such as server), and thus there's few need to consider the client selection. In cross-device setting, the heterogeneous issue arises, but typically this setting consists of a large number of clients, and thus select a proportion of them could maintain a certain level of protection. **Reply to Q2-d** We would like to highlight that: - The reduced message size from RFLPA compared with BREA is much larger than the extra latency in WAN setting, as is deomstrated in our previous reply. - The extra latency in more communication rounds is negligible compared with the reduced computation time from RFLPA compared with HE-based methods. As is shown by Appendix L.7.1 and our initial rebuttal, the computation time for RFLPA is hours fewer than the HE-based methods for even a single iteration. Therefore, the total communication latency (100s) is much smaller. Furthermore, the communication rounds in SecAgg [1][2] is 4 for each iteration. The reviewer can refer to their algorithm for further description.

Reviewer aBFW5/10 · confidence 4/52024-07-08

Summary

The paper proposes a defense mechanism against poisoning attacks on federated learning while maintaining privacy guarantee. The solution is based on secure aggregation and evaluates the trustworthiness of client updates with cosine similarity. Information leakage during the computation of cosine similarity is mitigated by a novel aggregation method for dot products. Theoretical and empirical analysis show that the defense successfully reduces the communication and computation overhead and keeps a competitive accuracy compared to previous work.

Strengths

1. The use of packed Shamir secret sharing with the proposed dot-product aggregation sounds novel and reliable. 2. The security and efficiency of the framework is well supported by theoretical analysis and experiments. 3. The framework largely reduces the overhead of previous works and maintains good accuracy even when no poisoning attack is considered, making deployment more practical.

Weaknesses

1. The paper focuses on a specific type of federated learning setup. Its applicability to other federated learning models, such as those involving more dynamic and heterogeneous client populations, is not explored. 2. The experiments conducted use standard datasets like MNIST, F-MNIST, and CIFAR-10. These datasets, while commonly used, do not fully represent the complexity and diversity of real-world data. The effectiveness of RFLPA in more diverse and complex datasets remains to be tested. 3. The performance comparison against other state-of-the-art methods might not be exhaustive. There might be other emerging methods or variations of existing ones that were not considered in the evaluation.

Questions

In section 4.2 normalization, should the gradients with norm smaller than $||g_0||$ also be normalized? If so, how to verify that they are normalized?

Rating

5

Confidence

4

Soundness

3

Presentation

3

Contribution

2

Limitations

The paper has adequately addressed its limitations.

Reviewer 4mMR7/10 · confidence 4/52024-07-12

Summary

This paper aims to enhance the vulnerability of FL when dealing with poisoning attacks. A common strategy used in FL to avoid directly sharing local updates is called secure aggregation(SecAgg), which works with ciphertexts and is incompatible with defense techniques against poisoning attacks. To address this issue, the paper proposes using verifiable packed Shamir's secret sharing to compute the cosine similarity between local and global models for aggregation. Additionally, a novel dot product aggregation method is introduced to reduce the communication overhead caused by Shamir's secret sharing.

Strengths

+ The problem of addressing poisoning attacks in FL is timely and challenging, especially with provable security guarantee + The attempt to reduce the communication overhead caused by secret sharing is valuable + Extensive experimental validations and very detailed comparison with existing frameworks, especially for various aggregation methods

Weaknesses

- The assumption that the server has trusted root of clean datasets seems a fundamental limitation - The presentation could be improved; there are too many concepts introduced, making it hard to distinguish between what is new and what is from existing literature.

Questions

1. It seems that only the experiments of malicious users are examined. I could not find that case when server conducts an active inference attack, is it included? 2. If the clean dataset at the server is not available, is it still possible to adjust the proposed protocol to deal with this situation?

Rating

7

Confidence

4

Soundness

4

Presentation

2

Contribution

3

Limitations

Limitations are adequately addressed

Reviewer WU566/10 · confidence 4/52024-07-16

Summary

This paper presents a framework to address the dual challenges of privacy leakage and poisoning attacks in federated learning. The authors propose RFLPA, which integrates cosine similarity for robust aggregation with verifiable packed Shamir secret sharing to ensure secure aggregation without compromising on robustness. The framework also introduces a new dot-product aggregation algorithm to prevent information leakage. The proposed method is evaluated on 3 benchmark datasets.

Strengths

The paper is well-written and well-structured. The paper addresses a very important problem in the security of federated learning systems. Thorough experimentation and analysis are undertaken to evaluate the proposed method.

Weaknesses

The paper’s reliance on the assumption that the server has a clean root dataset and that secure communication can be maintained without significant overheads may not always be realistic. Additionally, the code was not revealed and could not be evaluated at the time of this review. Finally, one of the main threats that challenge robust aggregators is backdoor attacks, which are tested on the proposed method.

Questions

1. Could the authors provide more insights into the practical implementation challenges of integrating verifiable packed Shamir secret sharing into existing FL systems? 2. How does the framework scale with the number of clients and the dimensionality of models, and are there potential bottlenecks for large-scale deployments? 3. Could the authors elaborate on the potential vulnerabilities in the cryptographic mechanisms used and how they are mitigated? 4. How realistic is the assumption of the server having a clean root dataset in different FL application domains, and can the framework be adapted for scenarios without such a dataset?

Rating

6

Confidence

4

Soundness

3

Presentation

3

Contribution

2

Limitations

Yes

Reviewer aBFW2024-08-10

Thanks for the response. The author has addressed my concern and I will keep my score.

Authorsrebuttal2024-08-10

Dear Reviewer aBFW, Thanks for your reply. We appreciate your recognition in the *novelty*, *soundness*, and *effectiveness* of our paper. We are pleased to know that we have addressed your concern. If you have any remaining concern, feel free to let us know. Best Regards, Authors of Submission 11258

Reviewer WU562024-08-11

Thank you for the provided answers. My questions are answered, and my decision remains the same.

Authorsrebuttal2024-08-11

Dear Reviewer WU56, Thanks for your reply. We are happy that the Reviewer found *our work addressing a very important problem and the empirical evaluation thorough*. We are pleased to know that we have addressed your questions and concerns. If you have any remaining concern, feel free to let us know. Best Regards, Authors of Submission 11258

Reviewer 4mMR2024-08-11

Thank you for the response. My concerns have been addressed, and good to see that the experimental results using DLG align with our expectations. My score remains unchanged.

Program Chairsdecision2024-09-25

Decision

Accept (poster)

© 2026 NYSGPT2525 LLC