- The paper integrates ML-KEM-512, Ascon encryption, K3s orchestration, and RabbitMQ messaging into a hardware-validated federated learning framework for IoMT devices.
- The distributed architecture reduces key-exchange latency by about 83% with 10 devices and 91% with 20, while model-exchange latency falls by roughly 59% and 66%, respectively.
- The framework improves scalability but introduces coordination overhead below five devices and leaves energy use, model-poisoning defenses, gradient-leakage protection, and broker resilience for future evaluation.
Motivation and problem statement
The Internet of Medical Things (IoMT) combines two properties that are difficult to reconcile: highly sensitive, long-lived health data and severely resource-constrained devices. The paper under review addresses the intersection of three pressures on this ecosystem. First, widely deployed public-key schemes (RSA, ECC) rest on hardness assumptions—integer factorization and discrete logarithms—that Shor's algorithm breaks on a sufficiently large quantum computer, and healthcare devices often have lifecycles long enough that "harvest now, decrypt later" adversaries are a realistic concern. Second, federated learning (FL), while avoiding centralization of raw patient data, introduces its own attack surface: gradient inversion attacks can leak private information from model updates (2606.14515). Third, post-quantum cryptography (PQC) primitives such as lattice-based key encapsulation are computationally heavier than their classical counterparts, which is problematic for wearables, implants, and bedside monitors.
The authors' position is that these three concerns must be addressed jointly rather than in isolation. Prior work, they argue, has treated them separately: Kubernetes-based FL orchestration frameworks for IoMT use conventional cryptography [10592425], while quantum-safe FL evaluations run on high-performance computing platforms rather than constrained edge hardware [appiah2025enhanced]. The paper's contribution is a unified framework that integrates PQC-enabled secure FL, lightweight K3s orchestration, and hardware validation on a Raspberry Pi cluster.
Enabling technologies
The framework is assembled from four NIST-standardized or widely adopted components:
- ML-KEM (FIPS 203) provides post-quantum key establishment via key encapsulation rather than direct secret transmission. It is based on the Module Learning With Errors (MLWE) lattice problem.
- Ascon, the NIST lightweight authenticated encryption standard, protects model updates and control messages with a footprint suitable for constrained devices.
- K3s, a stripped-down Kubernetes distribution with roughly half the memory footprint of standard K8s and ARM optimizations, orchestrates containerized services at the edge.
- RabbitMQ provides asynchronous, decoupled messaging between learning agents, security services, and devices, using quorum queues (Raft-replicated) to mitigate broker failure.
The security parameter choice is explicitly justified: ML-KEM-512 is selected over ML-KEM-768/1024 because both ML-KEM-512 and Ascon provide approximately 128-bit classical security, so higher KEM parameter sets would add overhead without raising end-to-end protection above Ascon's strength. This is a defensible matched-strength argument, though it does mean the system's quantum security level is bounded by the weakest primitive in the chain—an assumption the paper states but does not deeply analyze.
Architecture
The testbed consists of three Raspberry Pi 4 nodes running Raspberry Pi OS Lite (64-bit): one control-plane node and two workers, interconnected via a network switch with services exposed through NodePort. Three pod types are deployed from ARM64 Docker images:
- An FL pod that aggregates local models (LMs) and distributes the global model (GM).
- One communication pod per IoMT device, handling key exchange, encryption/decryption, and model transmission.
- A RabbitMQ pod managing message queues.
Three RabbitMQ exchange patterns structure the workflow: a basic queue collects decrypted LMs for aggregation; a fanout exchange distributes new GMs near-simultaneously to all communication pods; and direct exchanges with unique routing keys enforce isolated one-to-one channels between each pod–device pair. Each round proceeds as: ML-KEM key establishment → GM distribution → encryption and delivery → local training on-device → encrypted LM return → aggregation.
A notable design decision is that the framework does not implement a specific FL algorithm; aggregation and local training protocols are left pluggable. This improves generality but means the paper evaluates only the communication and cryptographic substrate, not learning performance or robustness against poisoning or gradient leakage—the very FL-layer vulnerabilities cited in the motivation.
Results
The evaluation compares the distributed architecture against a sequential baseline in which one program performs all key exchange, encryption, decryption, and distribution operations consecutively per device. Two headline results:
| Devices |
Key exchange latency reduction |
Model exchange latency reduction |
| 10 |
~83% |
~59% |
| 20 |
~91% |
~66% |
Key exchange latency under the distributed design remains approximately constant as device count grows, while the sequential baseline scales linearly. Model exchange latency grows in both cases, but far more gradually in the distributed architecture. These are strong numbers, and they support the paper's central claim that parallel cryptographic processing across communication pods makes PQC overhead manageable at scale.
The results also contain an honest negative case: at low device counts the distributed architecture's coordination overhead dominates. With a single device, the distributed design exhibits higher latency than the sequential approach due to queue-based coordination; gains become significant only beyond roughly five devices. This threshold behavior matters for small clinical deployments and should temper interpretation of the aggregate latency figures.
Limitations and open questions
The paper concedes several limitations directly. The RabbitMQ broker remains a potential single point of failure despite quorum queues; broker outages can temporarily disrupt FL rounds. PQC computation imposes energy overhead on battery-powered sensors and implants, and the paper has not yet performed empirical power-consumption profiling—this is deferred to future work on the same testbed. Interoperability across heterogeneous vendor ecosystems requires standardized lightweight cryptographic profiles that do not yet exist. Additionally, because no concrete FL algorithm or adversarial defense is implemented, questions about model poisoning resistance, update-privacy guarantees against gradient inversion, and end-to-end accuracy under the added latency remain open. Whether the constant-latency key exchange result holds on hardware weaker than a Raspberry Pi 4, or with ML-KEM parameter sets above 512, is likewise untested.
Conclusion
This work delivers a practical, hardware-validated integration of NIST-standardized PQC (ML-KEM-512 + Ascon) into an FL-enabled IoMT pipeline orchestrated by K3s, demonstrating that distributed cryptographic execution reduces key exchange and model exchange latency by 59–91% at 10–20 devices relative to sequential processing, at the cost of coordination overhead below five devices. Its principal value is as a reference implementation and benchmark for quantum-resilient edge FL; its principal gaps are the absence of energy measurements, learning-layer security evaluation, and standardized interoperability profiles.