Source-linked AI summary
EIFL: Efficiently Protecting Global Model Privacy and Integrity Against an Untrusted Server in Federated Learning
Zehui Liao, Qiang Li, Binghui Wang
TL;DR
Untrusted servers may tamper with the global model, and some settings require keeping it confidential; existing verification can depend on secret auxiliary information. EIFL combines two-stage aggregation and symmetric encryption with vector-inner-product verification and random-vector generation, and evaluation reports lower computation and communication overhead than state-of-the-art schemes.
Problem
Untrusted servers may return tampered global models, and privacy-sensitive scenarios may require keeping the global model confidential; existing verification schemes can be circumvented if confidential auxiliary information leaks.
Source: §I · p. 1Method
EIFL uses two-stage aggregation with symmetric encryption for output privacy, plus vector-inner-product verification and random-vector generation that binds auxiliary information to output integrity without hiding it from the server.
Source: §I · p. 2Results
EIFL’s security goals are theoretically guaranteed, and evaluation reports advantages over state-of-the-art schemes in computation and communication overhead.
Source: §I · p. 2Takeaways & Limitations
EIFL is designed to protect output privacy and address output-integrity verification vulnerability without requiring auxiliary information to remain confidential from the server.
Source: §VII · p. 12
Abstract
from arXiv · showhide
Federated learning (FL) typically adopts a server-client architecture, where the server aggregates clients' local models (i.e., the input) and returns the aggregated global model (i.e., the output) to clients. An untrusted server may return a tampered global model to compromise the output integrity. Some existing schemes focus on verifying the output integrity. However, these schemes mostly rely on clients pre-negotiating a set of identical auxiliary information among themselves and keeping it confidential from the server. This dependency creates a verification vulnerability: if the auxiliary information is leaked, the verification method may be circumvented. Additionally, in some privacy-sensitive scenarios (e.g., commercial federated learning), the global model may need to be kept confidential from an untrusted server. However, only a few works achieve the output privacy while addressing verification vulnerability, at the cost of prohibitive computation and communication overhead. To address these challenges simultaneously, we propose a novel provably privacy-preserving FL method called EIFL. Specifically, we adopt a two-stage aggregation and combine it with symmetric encryption to protect the output privacy. To address the verification vulnerability, we propose an efficient verification method based on vector inner product for output integrity, and a random vector generation method for clients to agree on auxiliary information. EIFL innovatively binds the auxiliary information to the output integrity, and eliminates the need to keep the auxiliary information confidential from the server. Moreover, EIFL is robust against client dropout during the verification phase through a simple resending operation. Evaluation results validate the advantages of EIFL over state-of-the-art schemes in terms of computation and communication overhead.
I. INTRODUCTION
The introduction frames EIFL around protecting global-model privacy and integrity from an untrusted server, while related work shows trade-offs in existing approaches. EIFL combines two-stage aggregation and symmetric encryption with vector-inner-product verification and random-vector generation.
I. INTRODUCTION
- Untrusted servers may return tampered global models, while some privacy-sensitive settings also require keeping the global model confidential from the server.Existing verification schemes may depend on identical auxiliary information kept secret from the server; leakage can let a malicious server bypass verification.Source: §I · p. 1
- EIFL combines two-stage aggregation with symmetric encryption for output privacy, and vector-inner-product verification with random-vector generation to address output-integrity vulnerabilities.Its auxiliary information is bound to output integrity without needing to remain confidential from the server.Source: §I · pp. 1–2
- EIFL’s evaluation is reported to show advantages over state-of-the-art schemes in computation and communication overhead, and its security goals are theoretically guaranteed.The introduction describes the added overhead as lightweight relative to the original secure aggregation protocol.Source: §I · p. 2
A. Secure Aggregation
- Secure aggregation computes the sum of clients’ local models without revealing those models, using approaches including differential privacy, MPC, and homomorphic encryption.The passage notes utility loss for current DP schemes, many communication rounds for MPC schemes, and prohibitive computation for homomorphic encryption.Source: A. Secure Aggregation · p. 2
B. Secure Aggregation Against Untrusted Server
- Prior output-privacy schemes use homomorphic encryption or Lagrange interpolation, while verification schemes use hashes, pairings, or random transformations and may depend on confidential auxiliary information.VCD-FL moves auxiliary-information negotiation until after server computation but incurs substantial peer-to-peer communication; the cited output-privacy approaches incur substantial computation overhead.Source: §I · p. 1, B. Secure Aggregation Against… · p. 2
C. Byzantine-robust Aggregation Against Malicious Clients
This material reviews Byzantine-robust aggregation and introduces preliminaries used by EIFL. It describes federated learning, Shamir secret sharing for dropout and privacy, and symmetric encryption requirements.
C. Byzantine-robust Aggregation Against Malicious Clients
- Byzantine-robust aggregation addresses malicious clients that send poisoned updates, with existing methods filtering or clipping updates before aggregation and assuming a reliable server.The passage describes Krum, median-based aggregation, Bulyan, FLTrust, and FLAME, while noting these methods are not fully effective or make specific assumptions.Source: C. Byzantine-robust Aggregation… · p. 3
III. PRELIMINARIES
- The preliminaries introduce cryptographic primitives, the threat model, and EIFL’s design goals.They are presented to facilitate understanding the proposed protocol.Source: §III · p. 3
A. Federated Learning.
- In federated learning, clients locally minimize empirical loss on private datasets using the server’s global model, then upload updated local models for aggregation.FedAvg is given as an example in which the server takes a weighted average to update the next global model.Source: A. Federated Learning · p. 3
B. Secret Sharing
- EIFL uses Shamir’s t-out-of-N secret sharing to handle client dropouts and preserve input and output privacy; t is the minimum number of clients needed to recover the secret.The sharing operation distributes shares among clients, and reconstruction takes at least t shares.Source: B. Secret Sharing · p. 3
C. Symmetric Encryption
- EIFL’s symmetric encryption scheme protects client privacy and authenticates identities, with IND-CPA security and ciphertext integrity required.Its algorithms generate a secret key, encrypt plaintext to ciphertext, and decrypt ciphertext back to plaintext.Source: C. Symmetric Encryption · p. 3
D. Key Agreement
EIFL’s design combines key agreement, signatures, and pseudorandom generation with a threat model centered on a malicious server and goals for output privacy, integrity, and dropout-resilient verification.
D. Key Agreement
- Diffie-Hellman key agreement creates a private shared key between each pair of clients.The protocol defines parameter generation, key generation, and agreement using one client’s secret key and another’s public key.Source: D. Key Agreement · p. 3
E. Signature Scheme
- One-time ECDSA signatures based on SHA-256 authenticate clients and protect the integrity of their masked gradient vectors.The scheme signs each client’s masked gradient vector as a message.Source: E. Signature Scheme · p. 3
F. Pseudorandom Generator
- The PRG produces computationally indistinguishable pseudorandom outputs when its seed is hidden and identical outputs for the same seed.These properties are stated as requirements for the generator used by EIFL.Source: F. Pseudorandom Generator · p. 4
G. Threat Model
- The model assumes semi-honest clients but a malicious server that may infer outputs, disrupt availability, or forge results using public verification information.Clients are not allowed to upload incorrect information to assist the server; Byzantine-robust aggregation against malicious clients is treated as a separate challenge.Source: G. Threat Model · p. 4
H. Design Goals
- EIFL targets output privacy, output integrity, and verification that can finish despite client dropout, with lightweight added overhead over double-mask secure aggregation.Client-local-model privacy is inherited from the underlying protocol rather than claimed as a novel contribution.Source: H. Design Goals · p. 4
IV. EIFL DESIGN
EIFL runs as a six-round upper-layer protocol over double-mask secure aggregation, splitting aggregation between a server-created masked intermediate result and client-side finalization. It uses masked inner products to verify output integrity and resends signed masked models to handle verification-phase dropouts.
A. Overview
- EIFL uses six rounds, with Round 2 creating a masked intermediate aggregate and Round 5 producing the global model locally at clients.Rounds 0 and 1 exchange information, while the two aggregation stages occur in Rounds 2 and 5.Source: A. Overview · p. 4
B. Workflow
- Clients establish shared masks, mask their local models, and send them for the server to sum into a masked intermediate result.The server’s intermediate result remains masked, so clients still remove masks locally to obtain the global model.Source: A. Overview · p. 4, B. Workflow · p. 5
- Signed masked local models let clients verify retransmitted dropout models, preventing the server from sending forged local models during verification.The server resends masked input vectors for clients that drop out before uploading inner products, so remaining clients can remove them from the intermediate result.Source: B. Workflow · pp. 5–6
- Clients derive a random vector from the intermediate result and use masked inner products with their local models to support integrity verification without exposing plaintext inner products.The verification vector is bound to the intermediate result; SHA-256 collision resistance and PRG randomness support detection of incorrect intermediate results with extremely high probability.Source: B. Workflow · pp. 5–6
- Clients encrypt information needed for mask recovery, then decrypt and reconstruct secrets to compute the final aggregate and verification value locally.This second aggregation stage uses the recovered masks to produce the global model and its corresponding inner-product value.Source: B. Workflow · p. 6
- Clients accept the aggregate only when the computed verification value equals the inner product of the agreed vector and global model.A mismatch signals malicious server behavior.Source: B. Workflow · p. 6
C. Complexity Analysis
The complexity analysis assumes a single server, N clients with model vectors of length M, and a fixed client dropout rate.
C. Complexity Analysis
- The analysis assumes fixed dropout rate and tracks N clients, model length M, and dropouts in both protocol phases.Nd and Nv denote dropouts in the non-verification and verification phases, respectively.Source: C. Complexity Analysis · p. 6
- The stated client computation complexity is O(MN^2).The analysis introduces nine parts contributing to each client’s computation cost.Source: 1) Computation Complexity of Client · p. 6
- Client computation is analyzed by separating its total cost into nine component operations.The supplied passage identifies the count of components but does not enumerate their details here.Source: 1) Computation Complexity of Client · p. 6
1) Computation Complexity of Client:
The protocol’s per-client costs are O(MN^2) for computation and O(N^2 + MN) for communication under the stated complexity analysis.
1) Computation Complexity of Client:
- The computation accounting includes key agreements, secret sharing, per-entry PRG generation, masked inner products, signatures, and dropout-secret reconstruction.The passage identifies PRG generation as O(MN), masked inner-product work as O(M + N), and reconstruction as O(N^2).Source: 1) Computation Complexity of Client · pp. 6, 8
- O(MN^2) is the overall computation complexity for each client.The analysis includes PRG generation, inner-product computation, signatures, and reconstruction of dropout secrets among its cost components.Source: 1) Computation Complexity of Client · pp. 6, 8
- O(N^2 + MN) is the total communication cost for each client, with Round 3 at O(MN) and Round 4 at O(N^2).The communication analysis also counts public keys, ciphertexts, masked input-signature pairs, and inner-product value-signature pairs.Source: 2) Communication Complexity of Client · p. 8
2) Communication Complexity of Client:
The excerpt gives asymptotic costs for server intermediate-result generation and server communication, then introduces the scope and notation of EIFL’s security analysis.
2) Communication Complexity of Client:
- Generating the Round 2 intermediate-result vector from N − Nd masked inputs takes O(MN) time.The server performs this generation using the masked input vectors of N − Nd clients.Source: 3) Computation Complexity of Server · p. 8
3) Computation Complexity of Server:
- Server communication totals O(N^3 + MN^2) across five protocol rounds.The listed exchanges include public keys, ciphertexts, masked input-signature pairs, and scalar value-signature pairs.Source: 4) Communication Complexity of Server · p. 8
V. SECURITY ANALYSIS OF EIFL
- EIFL’s security analysis examines output privacy and integrity under its corresponding threat model.Clients who correctly upload data through round k − 1 are denoted Ck, with C5 ⊆ C4 ⊆ C3 ⊆ C2 ⊆ C1 ⊆ C.Source: §V · p. 8
A. Output Privacy
EIFL’s security analysis formalizes output privacy and integrity. It argues that a simulator can reproduce the server’s view without aggregation outputs, while client verification checks the aggregate against a vector inner-product relation.
A. Output Privacy
- A PPT simulator can reproduce the corrupted server’s view computationally indistinguishably without knowing clients’ aggregation outputs.The privacy proof uses a hybrid argument, with Round 4 ciphertext replacement as its key step.Source: A. Output Privacy · p. 8
B. Output Integrity
- For surviving clients C4, output g is exactly their gradient sum if and only if Com == V · g.V is generated via a pseudorandom generator, and Com denotes the aggregated inner-product values.Source: B. Output Integrity · p. 9
- The output-integrity proof assumes a collision-resistant hash and a cryptographically secure PRG, and separates completeness from soundness.Completeness means honest execution passes verification; soundness means a PPT malicious server cannot forge a verifiable invalid output except with negligible probability.Source: B. Output Integrity · p. 9
1) Completeness (Honest Execution Passes Verification):
In honest execution, clients’ masked inputs are aggregated, surviving clients account for dropouts, and the resulting aggregate satisfies the verification equation by inner-product linearity.
1) Completeness (Honest Execution Passes Verification):
- Clients mask their inputs, and the server sums the masked vectors to form the valid intermediate result.The described inputs come from clients in C3.Source: 1) Completeness (Honest Execution… · p. 9
- Surviving clients offset masks for clients who drop before Round 3 and sum the original inputs of clients in C4.This produces the aggregate g over surviving clients.Source: 1) Completeness (Honest Execution… · p. 9
- By inner-product linearity, the summed client values equal V · g, so honest execution satisfies the verification equation.Only masked inner-product values from clients in C4 are uploaded; clients can calculate their sum of real inner-product values.Source: 1) Completeness (Honest Execution… · p. 9
2) Soundness (Unforgeability of Invalid Outputs):
EIFL’s soundness argument reduces a forged-output check to an exhaustive search under cryptographic assumptions, making a successful invalid-output forgery infeasible for a PPT server.
2) Soundness (Unforgeability of Invalid Outputs):
- The mask-removal term is independent of the server’s intermediate result, so the forged-versus-valid check cancels their common masked contribution.After cancellation, the adversary’s forgery goal reduces to satisfying the remaining inner-product equation.Source: 2) Soundness (Unforgeability of… · p. 9
- Exhaustive search over the vector space costs O(2^lm), making a successful invalid-output forgery infeasible for a PPT server except with negligible probability.The passage defines l as the bit length of each vector element and M as the vector dimension.Source: 2) Soundness (Unforgeability of… · p. 9
B. Model Accuracy and Convergence Rounds
EIFL has marginal effects on accuracy and convergence rounds relative to FedAvg. Its runtime analysis finds that verification grows slowly with client count or model dimension, while overhead mechanisms differ by round.
B. Model Accuracy and Convergence Rounds
- EIFL causes negligible classification-accuracy degradation and requires marginally more convergence rounds than FedAvg.The evaluation used 100 clients and Fashion MNIST, CIFAR10, and Federated EMNIST.Source: B. Model Accuracy and Convergence Rounds · p. 10
1) Runtime:
- Integrity-check costs in Rounds 3 and 5 rise with model dimension, while signature checks and privacy encryption/decryption costs in Rounds 4 and 5 rise with client count.Despite these increases, additional overheads remain insignificant relative to total overhead, and server computation remains very low.Source: 1) Runtime · p. 11
- Verification running time grows slowly as client count or model dimension increases, becoming a smaller proportion of total running time.Figure 3 compares verification and total per-client overhead across client counts and model dimensions.Source: 1) Runtime · p. 11, Figure 3 · p. 11
2) Data transfer volume:
EIFL compares favorably with existing verification schemes in verification time and communication, with verification communication scaling as O(N) rather than with model dimension. Dropout resending adds communication, while EIFL’s output-privacy encryption and decryption are faster than VCD-FL’s.
2) Data transfer volume:
- Verification data remains constant as model dimension grows, and its communication complexity is O(N); integrity-verification overhead grows slowly with client count and is negligible relative to total communication.Verification messages contain masked inner-product values and signatures of fixed length.Source: 2) Data transfer volume · p. 11
1) Verification performance for output integrity:
- EIFL maintains the shortest verification time and smallest verification communication overhead among VERIFL, VERSA, VOSA, and VCD-FL.VERIFL’s verification time is longest; VCD-FL, VERSA, and VOSA have communication costs tied to model-dimension-sized commitments or evidential vectors.Source: 1) Verification performance for output… · pp. 11–12
3) Performance for output privacy:
- EIFL’s encryption and decryption times are much shorter than VCD-FL’s.EIFL uses AES to encrypt information sent to the server and decrypts it in a later round; VCD-FL uses polynomial interpolation and evaluation.Source: Table V · p. 12, 3) Performance for output privacy · p. 12
2) Addressing the verification vulnerability and dropout clients:
- EIFL’s resending operation handles clients that drop out before submitting verification evidence, but dropout raises its communication overhead; EIFL remains much lower than VCD-FL.EIFL’s verification time outperforms VCD-FL, and dropout has negligible impact on verification time for both schemes.Source: Figure 5 · p. 12, 2) Addressing the verification… · p. 12
VII. CONCLUSION
- EIFL combines two-stage aggregation and symmetric encryption with inner-product verification and random-vector generation, binding auxiliary information to integrity without requiring secrecy from the server.Source: §VII · p. 12