Source-linked AI summary
EIFFeL: Ensuring Integrity for Federated Learning
Amrita Roy Chowdhury, Chuan Guo, Somesh Jha, Laurens van der Maaten
TL;DR
Secure aggregation hides individual updates, making their integrity difficult to verify. EIFFeL enables secure aggregation of verified updates using checks expressible as arithmetic circuits with public parameters. With 100 clients and 10% poisoning, it matched a non-poisoned federated learner’s MNIST accuracy in 2.4s per iteration.
Problem
Secure aggregation masks individual updates from the server, leaving malformed updates that could poison the model difficult to detect.
Source: §1 · p. 1Method
EIFFeL instantiates SAVI to verify updates without observing them and supports integrity checks expressible as arithmetic circuits with public parameters.
Source: §1 · p. 1Results
2.4s per iteration let EIFFeL match a non-poisoned federated learner’s MNIST accuracy with 100 clients and 10% poisoning.
Source: §1 · p. 2Takeaways & Limitations
EIFFeL demonstrates the feasibility of efficiently instantiating secure aggregation of verified inputs for practical FL settings.
Source: §1 · p. 2, §10 · p. 14EIFFeL checks each update independently; supporting pairwise or outlier-based Byzantine-robust aggregation remains a future direction.
Source: §11.7 · p. 20
Abstract
from arXiv · showhide
Federated learning (FL) enables clients to collaborate with a server to train a machine learning model. To ensure privacy, the server performs secure aggregation of updates from the clients. Unfortunately, this prevents verification of the well-formedness (integrity) of the updates as the updates are masked. Consequently, malformed updates designed to poison the model can be injected without detection. In this paper, we formalize the problem of ensuring \textit{both} update privacy and integrity in FL and present a new system, \textsf{EIFFeL}, that enables secure aggregation of \textit{verified} updates. \textsf{EIFFeL} is a general framework that can enforce \textit{arbitrary} integrity checks and remove malformed updates from the aggregate, without violating privacy. Our empirical evaluation demonstrates the practicality of \textsf{EIFFeL}. For instance, with $100$ clients and $10\%$ poisoning, \textsf{EIFFeL} can train an MNIST classification model to the same accuracy as that of a non-poisoned federated learner in just $2.4s$ per iteration.
1 Introduction
Secure aggregation masks updates, making their integrity difficult to verify; EIFFeL enables privacy-preserving verification and reports practical training under poisoning.
1 Introduction
- Secure aggregation masks individual updates from the server, so malformed updates can evade audits and compromise model accuracy.Even a single malformed update can significantly alter the trained model.Source: §1 · p. 1
- SAVI verifies each update without observing it, aggregates only well-formed updates, and releases only the final aggregate in the clear.EIFFeL supports integrity checks expressible as arithmetic circuits with public parameters, including multiple checks of the learner’s choice on masked updates.Source: §1 · pp. 1–2
- 2.4s per iteration lets EIFFeL match a non-poisoned federated learner’s MNIST accuracy with 100 clients and 10% poisoning.EIFFeL also extends SNIP to a malicious threat model and its optimizations improve performance by at least 2.3×.Source: §1 · p. 2
- EIFFeL uses secret-shared non-interactive proofs (SNIP) and co-designs its architecture and cryptography to extend verification to a malicious threat model.SNIP requires multiple honest verifiers; the system’s optimization suite improves performance by at least 2.3×.Source: §1 · p. 2
2 Problem Overview
This overview defines the federated-learning setting and its privacy and integrity goals, then presents EIFFeL’s approach to secure aggregation with verified inputs.
2.1 Problem Setting
- Each FL iteration broadcasts model parameters, has clients compute local updates, aggregates those updates, and uses the aggregate to update the global model.The server may subsample clients; n denotes the clients participating in an iteration.Source: §2.1 · p. 2
2.2 Security Goals
- The goals are to protect honest clients’ updates beyond what the final aggregate reveals and to check each update against a public validation predicate.Honest clients are assumed to follow the protocol and have well-formed inputs.Source: §2.2 · p. 2
2.3 Threat Model
- The threat model allows a malicious server to deviate to recover raw updates and malicious clients to send malformed inputs or attack honest clients’ privacy and integrity.Malicious clients may also try to make an honest client’s well-formed update fail its integrity check.Source: §2.3 · p. 2
2.4 Solution Overview
- Prior work mostly focused on privacy; EIFFeL’s SAVI protocol supports validation predicates expressible as arithmetic circuits with public parameters.Shamir secret sharing supports input privacy, while SNIP and verifiable secret shares support integrity; clients verify one another, and the server uses threshold-share redundancy to robustly verify proofs and aggregate only verified updates.Source: §2.4 · p. 2
3 Secure Aggregation with Verified Inputs
SAVI formalizes secure aggregation that verifies inputs and includes only well-formed updates, while preserving privacy for honest clients.
3 Secure Aggregation with Verified Inputs
- SAVI returns an aggregate over a subset of clients whose inputs all satisfy the public well-formedness condition.Its definition covers integrity and privacy against a malicious server and malicious clients.Source: §3 · pp. 2–3
- SAVI privacy is defined by a simulator that generates parties’ views using the honest clients’ identities and their aggregate.The privacy guarantee excludes information that malicious clients may reveal themselves.Source: §3 · p. 3
- The server is treated as honest for input integrity, although it may be malicious for input privacy.The authors exclude a malicious server’s acceptance of an invalid malicious-client input from the integrity threat because that conflicts with the server’s goal of ensuring well-formed inputs.Source: §3 · p. 3
- Detecting and removing malformed inputs lets the server train on valid updates, whereas detection alone can let an adversary cause denial of service by forcing a round to abort.The protocol’s integrity constraint requires malformed inputs to be detected and removed before aggregation.Source: §3 · p. 3
4 EIFFeL System Description
EIFFeL combines secret-shared proofs and an adaptation of SNIP to verify client updates against flexible integrity checks in a single-server federated-learning setting, securely aggregating only updates that pass. Its design distributes verification and adds threshold-sharing mechanisms to support verification despite malicious verifiers.
4.1 Cryptographic Building Blocks
- SNIP lets multiple verifiers check a private input against an arithmetic-circuit predicate without learning the input, with completeness, soundness, and zero-knowledge guarantees.Shamir sharing supports robust reconstruction through its Reed-Solomon code interpretation, tolerating q errors and e dropouts when 2q + e < n − t + 1; EIFFeL uses Gao’s decoding algorithm.Source: §4.1 · p. 4
4.2 System Building Blocks
- EIFFeL requires a public arithmetic-circuit predicate for update well-formedness, whose parameters may come from a clean public dataset, and a public bulletin board for broadcasting.The bulletin board is described as an append-only log accessible to all parties.Source: §4.2 · p. 5
4.3 EIFFeL Design Goals
- EIFFeL’s design goals are flexible integrity checks, compatibility with existing federated-learning infrastructure, and efficient performance.Source: §4.3 · p. 5
4.4 EIFFeL Workflow
- For a public predicate Valid(·), EIFFeL uses SNIP to check each client update and aggregates only updates for which Valid(u) = 1.Clients act as verifiers for one another alongside the server; Shamir threshold sharing enables verification with malicious verifiers by providing redundant SNIP instantiations.Source: §4.4 · p. 5
- The server robustly reconstructs proof summaries despite q errors and e dropouts when 2q + e < n − m − 1, then excludes clients with failed proofs before aggregating survivors.EIFFeL uses a [n−1, m+1, n−m] Reed-Solomon code for reconstruction; clients can dispute wrongful exclusion using the public reconstruction transcript.Source: §4.4 · p. 7
- SNIP supports arbitrary arithmetic circuits for Valid(·), which the server can change each training iteration or combine into multiple checks.For multiple checks, the circuits return zero on success and the server uses random coefficients so a failed check makes the combined value nonzero with high probability.Source: §4.4 · p. 7
- EIFFeL targets FL deployments with one server, since a two-server design requires an independent party and both servers to share the training computation.The paper characterizes a collaboration between companies such as Meta and Google to train on their joint user base as unrealistic.Source: §4.4 · p. 7
- SNIP is chosen for efficiency: its performance is about three orders of magnitude better than zkSNARKs [28], while checking multiplication gates non-interactively with one polynomial identity test.The alternative of performing the entire aggregation under MPC would require a circuit with O(nd) multiplication gates, making it prohibitively costly; the malicious threat model would increase that cost further.Source: §4.4 · p. 7
- EIFFeL extends SNIP to a single-server setting with malicious clients and verifiers, using Shamir sharing, robust reconstruction, verifiable shares, and encrypted messages.Robust reconstruction is based on Reed-Solomon codes; the paper also describes optimizations for the new operations and for SNIP generally.Source: §4.4 · pp. 7–8
- Clients send 12 one-way communications and the server sends 9, with complexity analyzed in terms of client count n, malicious-client count m, and data dimension d.The analysis assumes |Valid| is O(d).Source: §4.4 · p. 8
5 Security Analysis
EIFFeL provides secure aggregation of updates verified against any public validation predicate expressible as an arithmetic circuit. Its security analysis establishes update integrity and privacy, while ensuring that the aggregate contains all honest clients’ updates or the protocol aborts.
Security guarantees
- EIFFeL is a SAVI protocol for public validation predicates expressible as arithmetic circuits, with the stated valid-client set condition.The theorem’s full malicious-client bound is split across the supplied passages, so it is not reproduced here.Source: §5 · p. 8
Integrity
- Every honest client’s update is accepted, while malformed updates are rejected with probability 1 − negl(κ).The proof of malformed-update rejection relies on requiring at least n−m−1 valid shares before a client is verified.Source: §5 · p. 8
- The final aggregate contains updates from all honest clients, or the protocol aborts.The analysis allows accepted clients with well-formed updates to be malicious in other protocol steps, provided reconstruction of the final aggregate succeeds.Source: §5 · p. 8
Privacy
- In Rounds 1–3, EIFFeL reveals nothing about an honest client’s update beyond whether it passes validation.The proof uses that only m shares corresponding to malicious clients can be revealed.Source: §5 · p. 8
- In Round 4, EIFFeL reveals nothing about an honest client’s update beyond what can be learned from the aggregate.The information revealed is either the aggregate or ⊥.Source: §5 · p. 8
6 EIFFeL Optimizations
EIFFeL’s optimizations reduce reconstruction and cryptographic costs, with probabilistic reconstruction trading a small failure probability for improved performance. Crypto-engineering changes reduce circuit size, communication, and computation while preserving the efficacy of validation under random projection.
6.1 Probabilistic Reconstruction
- The share-validation shortcut applies to proof shares, not update shares, because the final aggregate is unknown and must be reconstructed.The digest values are fixed, unlike the final aggregate.Source: §6.1 · p. 10
- 2.3× runtime improvement is reported when skipping verification of proof shares, with an additional small probability of failure.The server decodes two sampled client sets and accepts when their polynomials match.Source: §6.1 · p. 10
- For m ≤ √n − 2, robust reconstruction partitions clients into q + 2 sets of size m + 1 and uses matching polynomials to recover the secret.At least two partitions contain only honest clients; the secret is the matching polynomials’ constant coefficient.Source: §6.1 · p. 10
6.2 Crypto-Engineering Optimizations
- Replacing output equality checks with a product of differences reduces the validation circuit size at no stated cost.The product is zero when the validation function matches any of the listed accepted values.Source: §6.2 · p. 10
- When m < n/4, locally computing shares of the random digest saves a communication round and reduces its robust reconstructions from three to one.This uses Shamir’s multiplicative property for the digest computation.Source: §6.2 · p. 10
- Random projection with Walsh-Hadamard transforms reduces update dimension, lowering computation and communication while preserving validation efficacy in evaluation.The projection addresses costs that grow linearly with data dimension.Source: §6.2 · p. 10
7 Experimental Evaluation
The evaluation finds that EIFFeL’s integrity checks preserve plaintext-defense accuracy on most tested datasets, while runtime and communication costs scale with client count and update dimension. It also reports practical end-to-end runtimes and identifies proof verification as the costliest round.
7.1 Performance Evaluation.
- Communication grows quadratically in n and linearly in d; a client transfers 132MB at n=100, d=10K, and m=10%.The authors characterize this communication cost as acceptable because clients typically participate in FL iterations infrequently.Source: Figure 6 · p. 11, §7.1 · p. 12
- At n=100, d=1K, and m=10%, client runtime is 1.3s and server runtime is about 1s; both scale quadratically in n and linearly in d.The reported computation costs are dominated by O(mnd), with m a linear function of n.Source: §7.1 · p. 11, Figure 5 · p. 11
- Round 3 proof verification is the costliest round for clients and server, while Round 1 is negligible and the server incurs no Round 2 runtime.Verifying share validity dominates Round 3; proof generation in Round 2 involves only clients.Source: §7.1 · p. 11, Figure 7 · p. 11
- At n=250, EIFFeL is 18.5× more performant than BREA; at n=100, d=1K, and m=10%, its end-to-end iteration time is ∼2.4s.The evaluation compares end-to-end time with an unoptimized EIFFeL variant and BREA [80].Source: Figure 7 · p. 11, Table 2 · p. 11, §7.1 · p. 11
7.2 Integrity Guarantee Evaluation
- Across MNIST, EMNIST, and FMNIST, EIFFeL matches plaintext-defense accuracy in most cases; CIFAR-10 accuracy drops ~7% after projecting 273K parameters to 10K.For MNIST, EMNIST, FMNIST, and CIFAR-10, end-to-end per-iteration times are 2.4s, 2.4s, 10.7s, and 20.5s, respectively.Source: Figure 8 · p. 12, §7.2 · p. 13
- Evaluation covers four integrity predicates against seven poisoning attacks, including sign-flip, scaling, noise, min-max/min-sum, and two backdoors.The attack tests include backdoors targeting digit-seven-to-one classification on EMNIST and green-car-to-bird classification on CIFAR-10.Source: §7.2 · pp. 12–13
8 Discussion
The discussion identifies limits in reconstruction, malicious-client identification, and client-side verification, while outlining future extensions for defenses and scalability.
Robust reconstruction
- Above the current decoding threshold, EIFFeL can detect malformed inputs but cannot remove them from the aggregate.The authors do not adopt a list decoder because reconstruction might sometimes fail.Source: §8 · p. 13
Handling Client Dropouts
- EIFFeL accommodates malicious-client dropouts, and the authors say extending this to honest-client dropouts is straightforward.This extension is discussed as a practical response to clients’ sporadic connectivity.Source: §8 · p. 13
Identifying All Malicious Clients
- EIFFeL currently identifies only a partial list of malicious clients; PVSS or Berlekamp-Welch decoding could identify all, but would cost more computation.The authors leave both approaches unused because of their higher computation cost.Source: §8 · p. 13
Reducing Client’s Computation
- Client verification of secret-share validity is currently the dominant client cost; offloading it with PVSS may increase end-to-end time due to public-key cryptography.PVSS permits any party to verify a share, but typically uses costlier public-key rather than symmetric cryptography.Source: §8 · p. 13
Additional Defense Strategies
- EIFFeL supports per-update anomaly-detection defenses, and defenses inspecting the final aggregate or model can also be integrated.The server has the final aggregate and updated model in the clear, enabling strategies such as Sparsefed, CRFL, and ensemble learning.Source: §8 · p. 13
Towards poly-logarithmic complexity
- The current dominant complexity term is O(mnd), yielding O(n^2) dependence on n when m is a fraction of n; techniques from could reduce it to O(n log^2 n d).The proposed reduction is discussed as a direction toward poly-logarithmic complexity.Source: §8 · p. 13
9 Related Work
Related work covers secure aggregation, Byzantine-robust learning, and integrity checks for secure aggregation; the comparison highlights EIFFeL’s broader validation support and malicious-server model.
Secure Aggregation
- Prior secure-aggregation work includes pairwise random masking and advances in communication overhead [18].Source: §9 · p. 13
Robust Machine Learning
Verifying Data Integrity in Secure Aggregation
- EIFFeL supports arbitrary validation predicates, whereas RoFL [23] is designed for range checks and assumes an honest-but-curious server; EIFFeL detects and removes malformed updates rather than aborting.The comparison is presented in Table 3.Source: Table 3 · p. 13, §9 · p. 14
- BREA [80] removes outlying updates but leaks pairwise input distances, while alternatives use two non-colluding semi-honest servers and are incompatible with FL.Source: §9 · p. 14
10 Conclusion
The conclusion formalizes secure aggregation of well-formed updates as SAVI and presents EIFFeL as an efficient system that instantiates it.
10 Conclusion
- SAVI formalizes secure aggregation of only well-formed inputs, and EIFFeL efficiently instantiates a SAVI protocol for practical federated-learning settings.Source: §10 · p. 14
11 Appendix
The appendix provides technical details of EIFFeL’s checks, costs, and security proofs, alongside supplementary accuracy results and discussion of extensions and future directions.
11.1 Building Blocks Cntd.
- SNIP encodes multiplication-gate wire values in shared polynomials; verifiers use a random evaluation to test consistency and catch malformed triples with high probability.They also reconstruct the circuit’s output wire and accept only when it equals 1, subject to the polynomial identity test’s failure probability.Source: §11.1 · pp. 17–18
- Beaver triples enable secure multiplication of shared values; Shamir-share multiplicativity lets clients generate digest shares locally, saving one communication round and reducing λ reconstruction from three to one.The local optimization is compatible with robust reconstruction under the stated condition m < (n−1)/4.Source: §11.1 · pp. 18–19
11.2 Complexity Analysis
- O(mnd) bounds each client’s computation and communication, while the protocol uses 12 client and 9 server one-way communications, independent of the validation predicate.The server’s computation is O((n+d)n log^2 n log log n + md min(n,m^2)), and its communication is O(n^2 + md min(n,m^2)).Source: §11.2 · p. 19
11.3 Proof for Lemma 3
- Invalid-share senders are removed or must provide valid shares; passing clients’ proof summaries are reconstructed correctly, after which SNIP soundness applies.The proof distinguishes clients flagged by at least m+1 parties from those flagged by at most m.Source: §11.3 · p. 19
11.4 Proof for Lemma 5
- A coalition of m malicious clients and the server can access at most m shares of an honest client; with m+1 required for recovery, SNIP reveals only whether Valid(u_i)=1.The zero-knowledge property of SNIP limits the information disclosed during verification to the predicate result.Source: §11.4 · p. 19
11.5 Security Proof
- Under the stated bound on m, Theorem 7 gives a PPT simulator whose view of the corrupt parties and server is computationally indistinguishable from their real execution.The proof uses a hybrid argument, including a DDH-based change to keys shared between honest clients.Source: §11.5 · p. 20
- The final proof hybrids replace honest clients’ inputs with valid sampled values and reconstruct shares around the adversarial aggregate, relying on Shamir secrecy and stated cryptographic assumptions.The proof invokes VSS discrete-log security, IND-CCA encryption, threshold Shamir secrecy, and SNIP zero knowledge.Source: §11.5 · p. 20
11.6 Additional Evaluation Results
- The additional accuracy evaluation uses the same configuration as Section 7 and reports observations consistent with Section 7.2; Figure 9 plots test accuracy by iteration across datasets and attacks.The supplied passages provide no numerical accuracy values.Source: §11.6 · p. 20, Figure 9 · p. 21
11.7 Discussion Cntd.
- Publishing an equal number of honest clients alongside the malicious-client list could offer plausible deniability, while more advanced cryptographic hiding remains future work.The current implementation publishes a partial list of malicious clients.Source: §11.7 · p. 20
- When Valid(·) contains server secrets, multiple servers can compute the predicate [28], while a single-server solution remains future work.Source: §11.7 · p. 20
- EIFFeL checks updates individually, whereas secure Byzantine-robust aggregation based on pairwise update distances or cosine similarity and outlier removal remains a future direction [14] [24] [33] [34].Source: §11.7 · p. 20
- Repeated Valid(·) structures could use G-gates for efficiency, and extending SNIP with affine-aggregatable encodings could support complex rules such as mode [28].Source: §11.7 · p. 20
- Differential privacy could enable noisy aggregate release and add robustness guarantees through techniques such as [44] [84].Source: §11.7 · p. 20