The problem
Banks, telecoms and hospitals each see part of the threat landscape, and none of them can share raw network traffic: regulation and competition forbid it. A traditional intrusion detection model needs a central data repository — a single point of failure and a high-value target. Federated learning turns the problem around: the model travels, the data does not. Each organisation trains locally and sends only model updates.
FedSentinel is a research prototype I built to study what that promise costs in practice. Sharing updates instead of data opens new attack surfaces: a participant can poison the model, free-ride on others, or try to reconstruct someone else's training data from the gradients. The project implements those attacks and the published defences against them, side by side, on top of the Flower framework and PyTorch.
This is a study project, not a product, and I would rather say where it stops. The dashboard shown below is a demonstration interface that runs on simulated data generated in the browser; its figures illustrate what each module reports, they are not measurements. The README gives benchmark figures on NSL-KDD, a 1999 dataset useful for validating a method and not representative of modern traffic; I do not present them here as verified results because the repository does not ship the run logs behind them.
Threats to the training itself, and their defences
| Threat | Attack implemented | Defence implemented |
|---|---|---|
| A participant poisons the model | Sign flip, scaling, Min-Max, inner-product manipulation, label flipping, backdoor trigger | Krum and Multi-Krum, trimmed mean, coordinate median, FLAME, FLTrust |
| A participant contributes nothing | Free-rider: near-zero update, replay, disguised copy | Update-norm and cosine-similarity detector; Shapley-value contribution scoring |
| The server learns about private data | Membership inference (loss threshold, shadow model) | DP-SGD with gradient clipping and Gaussian noise, RDP and GDP accounting, pairwise-mask secure aggregation, CKKS homomorphic encryption (TenSEAL) |
| Training data is reconstructed from the model | Model inversion by repeated queries | Noise on internal representations, output randomisation, per-source query budget |
| The detector is evaded | PGD adversarial examples | Adversarial training with mixed clean and perturbed batches |
| An update is altered after the fact | — | SHA-256 commitment with challenge-response, mutual TLS between server and clients, hash-chained audit log |
Two labels I refused to use
Security projects are easy to oversell with the right vocabulary. Two components of FedSentinel carry an explicit warning in the code documentation and in the interface itself:
- The gradient commitment scheme is not a zero-knowledge proof. It is a commit-challenge-respond protocol built on SHA-256 and HMAC. It binds a client to its update and proves knowledge of a key; there is no zk-SNARK or zk-STARK circuit behind it.
- The audit log is not a blockchain. It is an append-only, hash-linked list: tampering with one block invalidates every hash after it. There is no consensus, no distributed node and no smart contract.
Beyond the core loop
- Models: a Transformer encoder, a BiLSTM with attention and a graph attention network that classifies connections on the network graph, to catch coordinated activity a per-flow model misses.
- Unknown attacks: a variational autoencoder trained on normal traffic only, combined with an Isolation Forest; high reconstruction error flags what was never seen in training.
- Heterogeneous participants: asynchronous aggregation (FedBuff) with staleness weighting, personalised models (Ditto, pFedMe) and a federated MAML variant.
- Lifecycle: ADWIN concept-drift detection, federated unlearning for the right to erasure, model watermarking for ownership, gradient compression, SHAP and LIME explanations.
- Interfaces: a 12-command CLI, a FastAPI service, Docker Compose, and CI running lint, tests and Bandit.
The demonstration dashboard
A standalone command-centre interface built with Chart.js, with no framework, to show how an operator would read the system. As stated above, it runs on simulated data.
What I learned
- Privacy and robustness pull against each other. Robust aggregation needs to inspect individual updates; secure aggregation exists to hide them. Choosing one constrains the other, and that trade-off is a governance decision as much as an engineering one.
- Naming a control precisely is part of the control. Calling a hash chain a blockchain would not have changed the code; it would have changed what a reader believes it guarantees.
- Implementing a paper is the fastest way to find what its abstract leaves out — the assumptions on how many participants are honest, and on what the server is trusted to see.
- What I would do next: record reproducible benchmark runs on a recent dataset (CICIDS2017 or UNSW-NB15) and publish the logs with the numbers.