Federated Learning Security: Protecting Distributed AI Training
Federated learning distributes AI training across multiple clients — but each junction is a new attack surface. Gradient poisoning, model inversion and free-rider attacks can corrupt your global model while the training data stays "private". This guide covers all 5 FL-specific attack vectors with concrete, implementable defenses.
FL Attack Vectors & Defenses
Malicious FL client submits manipulated gradient updates that embed backdoors or degrade global model performance.
Defense: Byzantine-robust aggregation (Krum, FedMedian, Trimmed Mean). Clip gradient norms. Validate updates statistically before aggregation.
Attacker reconstructs training data from shared gradient updates, violating data privacy of other FL participants.
Defense: Differential privacy (DP-SGD): add calibrated Gaussian noise to gradients before sharing. Set privacy budget (ε ≤ 1.0 for strong privacy).
Client participates in FL without contributing genuine updates — downloads global model without sharing useful gradients.
Defense: Contribution verification: measure cosine similarity of submitted updates vs expected gradient direction. Ban clients below threshold.
Attacker infers membership of specific data points in training set from the global model's behavior.
Defense: Differential privacy provides mathematical membership inference resistance. Limit model query API access. Monitor for systematic probing.
Man-in-the-middle intercepts gradient updates in transit, modifies them, or injects malicious updates.
Defense: mTLS for all FL client-server communication. Authenticate clients with certificates. Sign all gradient updates. Verify signatures before aggregation.
Self-Hosted FL Setup (Flower Framework)
# Flower (flwr) — production-secure FL server config
import flwr as fl
from flwr.server.strategy import FedTrimmedAvg # Byzantine-robust
strategy = FedTrimmedAvg(
fraction_fit=0.3, # 30% clients per round
min_fit_clients=5, # Minimum 5 clients
min_available_clients=10,
beta=0.1, # Trim top/bottom 10% of updates
# Add differential privacy wrapper:
# strategy = DifferentialPrivacyServerSideAdaptiveClipping(
# strategy, noise_multiplier=1.1, num_sampled_clients=10
# )
)
fl.server.start_server(
server_address="127.0.0.1:8080", # localhost only
config=fl.server.ServerConfig(num_rounds=100),
strategy=strategy,
# mTLS via nginx reverse proxy in front
)
# Client authentication: verify X.509 cert before accepting updates
# Gradient norm clipping: max_norm=1.0 on all client updatesGDPR Compliance Advantages of FL
Data Minimisation (Art. 5)
Only gradient updates leave client systems — never raw personal data. Mathematical proof that reconstruction is computationally infeasible with DP.
Purpose Limitation (Art. 5)
Data stays in client systems under original purpose. Central server never processes personal data — only model updates.
No Third-Country Transfer
Self-hosted FL server in EU. No personal data leaves EU jurisdiction. No Schrems-II concerns, no SCCs required.
Residual Risk: Gradient Attacks
Without DP, gradient updates can still leak training data via model inversion. DP is mandatory for genuine GDPR compliance in FL.
Frequently Asked Questions
What is federated learning and why is it relevant for GDPR?
Federated learning trains AI models across multiple data sources without centralizing the raw data. Each participant trains locally and shares only model updates (gradients) — not the underlying data. This makes FL inherently privacy-preserving and GDPR-friendly: personal data never leaves the data controller's systems.
What is differential privacy in federated learning?
Differential privacy (DP) adds mathematically calibrated noise to gradient updates before they are shared, making it computationally infeasible to reconstruct individual training samples. The privacy budget (ε) controls the privacy-utility tradeoff: ε < 1.0 provides strong privacy, ε > 10.0 provides weak privacy. DP-SGD is the standard implementation.
How do I defend against gradient poisoning in federated learning?
Use Byzantine-robust aggregation algorithms instead of simple FedAvg: 1) Krum: selects the update most similar to its k neighbors. 2) Trimmed Mean: removes top/bottom x% of updates before averaging. 3) Median: takes the coordinate-wise median. Also: clip gradient norms before aggregation, monitor per-client update statistics over time.
Can I run federated learning on self-hosted infrastructure?
Yes. Frameworks like Flower (flwr), PySyft and TensorFlow Federated support fully self-hosted deployments. The FL server and all clients run on your infrastructure. No data ever leaves your network. Combine with mTLS client authentication and Moltbot monitoring for a production-grade, GDPR-compliant federated learning setup.