# A Secure and Trustworthy Network Architecture for Federated Learning
Healthcare Applications ††thanks: Funded by the EU in the call HORIZON-
HLTH-2022-STAYHLTH-01-twoStage under grant agreement No 101080564.

Antonio Boiano1, Marco Di Gennaro1, Luca Barbieri1, Michele Carminati1, Monica
Nicoli1, Alessandro Redondi1
Stefano Savazzi2, Albert Sund Aillet3, Diogo Reis Santos3, Luigi Serio3 1DEIB,
Politecnico di Milano, Milan, Italy
2IEIIT, Consiglio Nazionale delle Ricerche (CNR), Milan, Italy
3CERN, Geneva, Switzerland

###### Abstract

Federated Learning (FL) has emerged as a promising approach for privacy-
preserving machine learning, particularly in sensitive domains such as
healthcare. In this context, the TRUSTroke project aims to leverage FL to
assist clinicians in ischemic stroke prediction. This paper provides an
overview of the TRUSTroke FL network infrastructure. The proposed architecture
adopts a client-server model with a central Parameter Server (PS). We
introduce a Docker-based design for the client nodes, offering a flexible
solution for implementing FL processes in clinical settings. The impact of
different communication protocols (HTTP or MQTT) on FL network operation is
analyzed, with MQTT selected for its suitability in FL scenarios. A control
plane to support the main operations required by FL processes is also
proposed. The paper concludes with an analysis of security aspects of the FL
architecture, addressing potential threats and proposing mitigation strategies
to increase the trustworthiness level.

###### Index Terms:

Federated Learning, Trustworthy AI, Stroke Prediction

##  I Introduction

FL is a decentralized machine learning approach where a model is trained
across multiple edge nodes holding local data samples, without exchanging
them. Local data remain on the nodes where they originate, and only model
updates are shared, preserving the ownership and privacy of individual data
samples. Compared to classical centralized learning, where all data are
transferred to a central server for model training, FL offers clear advantages
in terms of privacy, communication efficiency, scalability, and robustness
compared to centralized learning, particularly in scenarios where data privacy
is a concern or where data is originally distributed across multiple nodes [1,
2, 3]. FL has become particularly appealing in the context of medical and
healthcare data, which is generally subject to very strict privacy
regulations. In this scenario, the TRUSTroke project [4] proposes a novel AI-
based platform to assist clinicians, patients and caregivers in the management
of acute and chronic phases of ischemic stroke. To this purpose, the project
has the ambitious goal to design, build and maintain a FL infrastructure that
will enable multiple hospitals and clinical sites to collaborate in training
AI models able to predict several variables related to stroke (e.g., clinical
severity at discharge, stroke recurrence, etc.) without sharing their data,
hence without compromising privacy. The FL platform envisioned by the
TRUSTroke project focuses particularly on trustworthiness, robustness and
privacy-preservation in all its building blocks, in line with the recent EU
Artificial Intelligence (AI) Act requirements. Such requirements hold not only
for the AI algorithms that will be developed for stroke prediction, but extend
also to any system-level component needed to run the FL platform, including
networking and communication aspects. In this regard, this paper proposes an
efficient, robust and secure network architecture, together with the related
communication protocols, to support trustworthy FL processes. In detail, the
contributions of this paper are the following:

  1. 1.

Network architecture: we propose in Section II a client-server architecture
for the FL process, where a central Parameter Server (PS) aggregates models
trained locally at different clinical clients. Both the PS and the clients are
designed in a containerized fashion to provide a portable, efficient, secure
and trusty operation.

  2. 2.

Communication protocols: we discuss the implications of using two different
communication paradigms, i.e., Request/Response or Publish/Subscribe to
support the operation of the FL platform. This is done in Section III by
comparing two widely popular protocols of different types, HTTP and MQTT: the
latter is selected as reference communication protocol for the proposed FL
platform due to a series of features which better fit with the FL scenario.

  3. 3.

Control and data plane design: Section IV provides an analysis of the
requirements of a FL platform in terms of fundamental operations the Parameter
Server and the clinical clients need to perform. Based on such an analysis,
MQTT-based control and data plane are proposed to support each FL operation
efficiently.

  4. 4.

Security considerations: additionally, Section V provides a summary of the
security threats and risks associated with each component of the proposed
architecture, as well as mitigation techniques and recommendations to be
compiled in order to increase the security and trust level.

Finally, Section VI concludes the paper and discusses future research
directions.

##  II TRUSTroke Network Architecture

Two main communication architectures are typically utilized in FL scenarios:
Client-Server (centralized) and Peer-to-Peer (decentralized) [5]. In the
centralized approach (Figure 1, left), edge nodes exchange model parameters
with a central PS, which aggregates these parameters to create a global model
disseminated back to the nodes. In contrast, decentralized FL involves nodes
exchanging parameters directly, without a central entity (Figure 1, right).
Decentralized FL offers advantages in communication efficiency and privacy but
requires complex orchestration and may suffer from inconsistency among nodes.
Hence, it is used with a massive number of nodes or when a trusted centralized
server isn’t available [6].

The TRUSTroke project leverages the involvement of CERN among its partners and
therefore opts for a centralized FL architecture. Indeed, CERN’s powerful
computing resources, stringent security measures, and well-known global
collaboration network makes it an ideal candidate for hosting the PS. CERN’s
infrastructure ensures data privacy and security, providing a trusted
environment for handling sensitive model updates. Therefore, the project
implements a centralized FL architecture, with CERN as the PS and clinical
partners as the edge nodes, as illustrated in Figure 2.

###  II-A Parameter server

The TRUSTroke PS is hosted within the CERN Data Centre as a containerized
application managed by a Kubernetes (K8s) cluster (Figure 2, left). The
container networking resources and security aspects are handled by the CERN
infrastructure. The key networking elements at CERN include:

  * •

Outer Perimeter Firewall: CERN’s network perimeter is protected by a PaloAlto
7080 firewall, offering deep packet inspection and policy-based IP, domain,
and URL blocking. It processes incoming and outgoing traffic at 200Gbps,
enhancing cybersecurity by blocking unauthorized access and known malicious
domains.

  * •

Linux Public Logon User Service (LXTUNNEL): LXTUNNEL enables authenticated
access to CERN computing resources and establishes encrypted communication
channels via SSH tunnelling, either with CERN account credentials or Kerberos
authentication tokens [7].

  * •

Parameter Server: The TRUSTroke PS runs within a containerized application
managed by the K8s cluster, configured to accept connections from clinical
nodes. Specific protocols for PS-to-client communication, along with
additional security mechanisms for accepting connections from clinical nodes,
are detailed in the following sections.

Figure 1: Centralized (left) vs Distributed (right) FL architectures Figure 2:
TRUSTroke network architecture: the Parameter Server is hosted within the CERN
data center and protected by the security mechanisms implemented thereby.
Clinical clients run a Docker-based architecture which (i) decouples sensitive
data processing from model parameters communication and (ii) provides
portability for easy implementation on different client infrastructures.

###  II-B Client nodes

Client nodes are represented by clinical institutions which federate their
knowledge (local AI models) to create a global model without directly sharing
their data. In order to do this, dedicated computing resources (either
physical or virtual machines) should be present at the clinical site premises:
such machines are required to connect to the PS in order to exchange the local
model parameters and contribute to the computation of the global model. The
TRUSTroke project has the ambitious goal of building a FL platform accessible
by any clinical institution, which may be characterized by specific IT
infrastructure, network policies, etc. To mitigate the differences and
complexities arising from the different setups at the clinical nodes and
designing an easy-to-use and plug-and-play solution for connecting nodes to
the PS, a container-based software architecture based on Docker is proposed
for the client nodes. The architecture is shown in Figure 2, right: as one can
see, the client infrastructure is composed of two main Docker containers named
the Jump Host container and the FL client container.

  1. 1.

FL client container: this container embeds all the functionalities needed for
FL operations, including local model training as well as exchange of
parameters with the PS through the Jump Host. Since the FL client container
needs access to data for local training, it is critical to isolate it as much
as possible from external access. Indeed, such a container is configured with
one single network interface, which is assigned a private address in a local
network not reachable from outside the clinical node’s internal network.

  2. 2.

Jump Host Container: this container is responsible for the external connection
of the clinical node to the PS and it is configured for such task, including
all needed dependencies for easier portability. As an example, the container
already contains all functionalities needed for the Kerberos authentication to
the CERN servers. The container leverages two different network interfaces,
for external and internal communication, respectively.

    1. (a)

The internal network interface is solely used for communication with the FL
client container. Such interface is assigned an address in the same private
local network of the FL client container, which is completely isolated from
the Internet.

    2. (b)

The external network interface is connected to the Internet and is programmed
to communicate with CERN’s LXTUNNEL server. The domain lxtunnel.cern.ch is
therefore whitelisted for outbound connections on any border firewall at the
clinical node’s premises. The Jump Host uses the external network interface to
connect to CERN through a SSH tunnel with port forwarding. All traffic
received by the Jump Host on the internal interface from the FL client is
therefore encrypted and forwarded to the PS.

Ultimately, such a container-based design for the client nodes offers two key
advantages:

  1. 1.

Consistency and portability: using Docker containers, which encapsulate
everything needed for FL communication and operation, ensure consistent
behavior across different environments, and simplifies the task of maintenance
and version control. Moreover, Docker containers are highly portable,
regardless of the actual underlying infrastructure: this ensures easy
migration and adaptation to different environments.

  2. 2.

Isolation and security: the proposed design provides several layers of
security both from internal and external threats. Indeed, containers provide
process and filesystem isolation, allowing multiple applications to run
independently on the same host without interfering with each other. This
isolation enhances security and stability by minimizing the impact of one
application’s issues on others. Moreover, the use of the Jump Host container
allows to decouple sensitive data processing for FL operations from model
parameters communication through the creation of a so-called Demilitarized
Zone (DMZ). The DMZ separates the internal from the external network, creating
a buffer zone that limits direct access to internal resources. Additional
capabilities such as intrusion detection/prevention system may be deployed
within the DMZ to further monitor and regulate traffic flows between the
internal and external networks.

##  III Communication protocols: HTTP or MQTT?

The definition of communication protocols is crucial for the operation of the
FL platform within the proposed network architecture. Two main components of
communication are identified: the control plane and the data plane. The
control plane manages network behavior, including network configuration,
client management, and access control, while the data plane handles the
forwarding of data packets between clients and the PS in the case of the
TRUSTroke FL platform.

For the implementation of the TRUSTroke control and data plane, various
communication protocols can be utilized. These protocols fall into two
categories based on their communication paradigm: Request/Response and
Pub/Sub. In Request/Response protocols, clients send requests to a server,
which replies in a one-to-one manner. In Pub/Sub protocols, a message broker
facilitates communication between publishers and subscribers, allowing one
publisher to reach multiple clients with a single transmission process. HTTP
and MQTT are widely recognized standards for the Request/Response and Pub/Sub
approaches, respectively.

The following list outlines the communication requirements for the TRUSTroke
FL platform:

  * •

Asynchronous communication:  the FL process is intrinsically asynchronous, as
clients train local models independently from each other and the PS aggregates
the received updates according to specific policies. MQTT’s asynchronous
nature and the publish-subscribe paradigm offer therefore a significant
advantage, compared to HTTP’s synchronous nature, which may require additional
mechanisms and complexity, such as long polling operations, to achieve similar
levels of efficiency and real-time communication between the clients and the
PS.

  * •

One-to-one/one-to-many communication: for one-to-one communication, both HTTP
and MQTT are efficient options for transmitting model parameters from local
clients to the parameter server (PS). HTTP request-response model enables
direct communication between individual clients and the PS. Similarly, MQTT
publish-subscribe model facilitates one-to-one communication, where clients
publish updates to specific topics subscribed to by the PS. However, in one-
to-many communication scenarios, MQTT holds a natural advantage due to its
publish-subscribe paradigm and the presence of a broker. Clients publish
updates to a topic, and multiple subscribers (such as the PS and potentially
other clients) can receive these updates simultaneously. This simplifies the
dissemination of global model parameters to multiple clients, as the PS can
publish updates to a topic that all clients subscribe to, ensuring efficient
distribution. Conversely, HTTP request-response nature complicates one-to-many
communication. To distribute global model parameters to multiple clients via
HTTP, additional mechanisms like message queues or specific transmission
policies are needed. This complexity and overhead contrast with MQTT built-in
support for one-to-many communication.

  * •

Security: the PS should exclusively accept connections from authenticated and
authorized clients. CERN’s existing security measures already ensure that only
clients with valid credentials can connect to the PS. Additionally, the
connection occurs over an encrypted channel from the client Jump Host to the
CERN Jump Host via the SSH tunnel. To enhance security further, additional
measures should be implemented to: (i) regulate the operations that a client
can perform on the PS, such as participating in FL tasks or accessing global
models, and (ii) encrypt communication between the FL client and the PS end-
to-end. For the latter objective, both MQTT and HTTP offer encryption via TLS.
Concerning the former, HTTP features an optional authorization mechanism that
requests client credentials to access specific resources. In contrast, MQTT
offers a natural approach to client authorization through topic access lists.
These lists allow for fine-grained access control based on client identifier
and permissions.

  * •

Efficiency and scalability: MQTT is indeed designed for efficient
communication with low overhead due to its binary-encoded message headers and
minimal length. This design makes it particularly suitable for scenarios where
bandwidth and resource usage need to be minimized. On the other hand, HTTP
relies on textual headers, which can introduce significant overhead,
especially for small payloads. However, both protocols can handle large
payloads effectively, as they do not impose specific upper limits on message
size. In terms of scalability, MQTT message brokers are naturally designed to
handle a massive number of clients, potentially in the order of millions. This
scalability is inherent to the publish-subscribe architecture of MQTT. In
contrast, HTTP web servers may require specific implementations and
optimizations to handle a large number of concurrent connections efficiently.
Overall, while both MQTT and HTTP are capable of exchanging large payloads,
MQTT’s efficiency and scalability make it well-suited for scenarios requiring
lightweight communication and handling a large number of clients.

Table I summarizes the main differences between HTTP and MQTT, demonstrating
that the Pub/Sub approach aligns better with the requirements of the TRUSTroke
FL platform. Therefore, the MQTT protocol has been selected as the
communication protocol to implement both the Control and Data plane for the
initial release of the TRUSTroke FL platform. It’s important to note that the
MQTT protocol requires an MQTT broker to act as an intermediary between
publishers and subscribers. This broker should ideally be located as close as
possible to the PS to minimize communication latency. Therefore, the TRUSTroke
FL platform’s MQTT broker can be deployed in the same virtualized instance and
local network as the PS, leveraging CERN’s abundant computational and
communication resources.

TABLE I: Communication protocols comparison Feature | HTTP | MQTT
---|---|---
Communication paradigm | Synchronous | Asynchronous
Authentication/authorization | Managed ad hoc | Provided by broker
Message encryption | Supported (TLS) | Supported (TLS)
One-to-many communication | Managed ad hoc | Provided by broker
Message overhead | 4-8KB | 2B min, 14B max
Max. payload size | No limit | 256MB
Scalability | Managed ad hoc | Provided by broker

##  IV TRUSTroke Control and Data plane

###  IV-A Control plane

In order to properly design the control plane for the TRUSTroke FL platform, a
requirement analysis of the functionalities of a generic Federated Learning
system has been conducted. This preliminary study also involved the analysis
of publicly available FL platforms such as Flower [8] and OpenFL [9]. The
following list details the control plane functionalities that have been
identified and how they are efficiently mapped to MQTT message exchange:

  * •

Client authentication and authorization: the PS will manage several concurrent
learning tasks, named Clinical End Points (CEPs). Each CEP responds to a
different objective and possibly require different data to be trained.
Moreover, different sets of clinical clients (i.e., multiple federations) may
be active at the same time, cooperating on specific CEPs. It follows that a
client may be willing to join only specific federations and CEPs managed by
the PS. A client’s request to join undergoes a screening process which
assesses the clinical client characteristics (security features, clinical
features needed for the learning model, etc.). If the screening process
results in a positive assessment, the clinical node receives a set of
credentials, namely: (i) a CERN account to be able to produce a Kerberos token
needed for SSH access to the CERN infrastructure, (ii) cryptographic material
needed for properly authenticating with the MQTT broker (either username and
password or a digital certificate), together with a unique MQTT client_id and
(iii) the set of topics it is authorized to publish and subscribe to (detailed
later). Note that both authentication and authorization mechanisms are
provided by most MQTT brokers and do not need to be implemented ad hoc in the
FL platform.

where client_id is the identifier assigned to the clinical client after the
screening process.

  * •

Client joining/leaving: Clients may need to join or leave federations
dynamically based on their needs or the availability of tasks. Joining a
federation allows a client to participate in collaborative learning, while
leaving a federation may occur if the client no longer wishes to contribute or
if its resources become unavailable. After successful connection to the PS
using the personal credentials, a client willing to join a specific federation
and CEP is simply required to perform a subscribe operation on the following
topic (named T1 for brevity):

fed_id/CEP_id/job_request (1)

where federation_id and CEP_id are the identifiers of the federation and CEP
the clients is willing to join, and for which it is authorized. Similarly, a
client willing to leave the FL process may simply unsubscribe from the
aforementioned topic.

  * •

Runtime operations: The PS and the client nodes use two specific MQTT topics
for exchanging the model parameters. In particular, the PS uses the topic (1)
to publish the initial model template and the computed global models to the
client. Conversely, the clients use the following topic for updating the local
parameters to the PS:

fed_id/CEP_id/job_replies/client_id

To receive such updates, the PS subscribes to:

fed_id/CEP_id/job_replies/#

The use of the hash wildcard allows to efficiently receive updates from all
connected clients in a single operation.

  * •

Global model versioning: This action involves managing the versioning of the
global model within the federated learning network. As the model evolves
through training iterations and updates from participating clients, versioning
ensures consistency and integrity across the network, allowing for proper
synchronization and coordination of learning efforts. At any point in time, a
client with authorized access may retrieve the list of global models available
on the PS for a specific federation and CEP. Such an operation is performed by
a client with a specific publish message on the topic, where the PS is
subscribed:

fed_id/CEP_id/model_request/client_id

The PS uses the following topic for replying:

fed_id/CEP_id/model_reply/client_id

The two topics create a bidirectional communication channel between any client
and the PS: the channel is used by (i) a client, to request the list of
available global models on the PS for the specific CEP, possibly including
information such as which other clients participated in the global model
training, (ii) a client, to request the download of a specific model version,
(iii) the PS to transmit the requested global model to a client.

###  IV-B Data plane

For what concerns the data plane, the MQTT protocol already offers the main
features needed for an effortless implementation. In particular:

  * •

Custom payload formats: MQTT payloads can be formatted in any custom format or
structure based on the specific needs of the application. This allows for
flexibility in designing message formats that best suit the requirements of
the application. In this specific case, MQTT payloads are used for
transmitting both control information as well as model parameters. We suggest
the use of compressed Protocol Buffer (protobuf) for the serialization of the
message payloads, rather than the transmission of uncompressed text-based JSON
payloads. This allows for smaller message sizes, faster serialization and
deserialization, and backward and forward compatibility.

  * •

Quality of service: MQTT offers three incremental levels of QoS, which can be
used as an additional error control method over the one already offered by the
TCP protocol. For the initial release of the TRUSTroke FL platform, given the
small size of the network scenario (one PS and three clinical clients) the
minimum level of QoS will be used and error control will be devoted to the
underlying TCP protocol. The QoS level may be easily increased to level 1 or
2, which requires acknowledgements also at the application layer, in case the
error control provided by TCP is not sufficient.

  * •

Encryption: all communications between clients and the PS will be
automatically encrypted end-to-end by TLS, which is naturally supported by
MQTT. TLS ensures that the data exchanged between MQTT clients and brokers is
encrypted and authenticated, thus enhancing the security of the data plane.

TABLE II: Security threats associated with the proposed architecture Threat |  Description |  Attacked component |  Mitigation
---|---|---|---
Data Breach/Leakage |  Unauthorized access to patient data poses a significant risk if client containers are compromised, potentially leading to severe privacy breaches and reputational damage to the TRUSTroke project. |  Clinical client |  The FL client and local dataset are isolated from external connections by design.
Data Interception and Tampering |  Unauthorized interception or alteration of model parameters and training data during transmission, which could impact the reliability and performance of global and local models. |  Communication infrastructure |  Use of MQTT data plane with TLS encryption
Unauthorized Access |  The risk of unauthorized individuals gaining access to client or server systems is high, especially if security measures outside the Federated Learning (FL) Client Container are inadequate. This could lead to data theft and system compromise, including access to the parameter server if security isn’t sufficient. |  Parameter Server, Clinical client |  Access to PS is regulated by SSH tunneling, Kerberos authentication and MQTT5 enhanced authentication. The client is made accessible only from within the clinical infrastructure network.
Denial of Service Attacks |  Overloading the PS MQTT broker to disrupt the training process. |  Parameter server |  Adopt MQTT5[10], which reduces the risk of DoS due to message queue filling at the broker.
Docker Configuration and Patch Management Failures |  Improper Docker system configuration or failure to apply security patches timely may expose the system to known vulnerabilities. |  Clinical client |  Follow Open Web Application Security Project (OWASP) guidelines for secure Docker configuration[11]

##  V Security considerations

Security measures are introduced for protecting data, preventing exploitation
and mitigating risks, overall fostering general confidence and trust in the
proposed solution. Table II provides a brief description of the threats and
risks associated with each component (Parameter Server, Clinical client or
Communication infrastructure) of the proposed architecture, as well as the
adopted mitigation technique. As one can see, the main identified threats are
well mitigated by the design choices taken within the proposed system.
Following the threat identification step, a series of security recommendation
may be compiled for each component of the proposed architecture.

###  V-A Parameter Server

In the context of server-side security and operational specifications, the
requirements primarily focus on authorization processes, access control for
services such as the parameter server and MQTT broker, and the education of
intern personnel on security protocols. It is pertinent to note that the
network infrastructure at CERN already complies with these established
requirements, furthermore highlighting CERN’s appropriateness as serving for a
public PS for FL processes.

###  V-B Communication infrastructure

The main requirements for the communication infrastructure are linked to
authentication and communication integrity and confidentiality. The use of SSH
tunnels and authentication with Kerberos together with MQTT authentication
primitives at the PS provides authentication. Similarly, using TLS with MQTT
allows for message integrity and confidentiality.

###  V-C Clinical clients

The clinical clients are probably the most vulnerable component of the
proposed architecture, given that (i) they host sensitive data and (ii) each
clinical client is based on a different IT infrastructure, possibly
implementing different security mechanisms. The proposed design for the client
node allows to mitigate many of the associated threats, although others
actions should be taken at the clinical infrastructure to increase security.
As an example, it is necessary to design an access control system that limits
direct access to the machine on which the containers run. During the design of
such an access control system, the principle of least privileges (PoLP) should
be applied, i.e., users should be given the minimum access levels or
permissions they need to perform their job functions. Furthermore, it is
important to conduct regular penetration testing and vulnerability assessments
on the client’s side. A robust patch management system should be implemented
to ensure timely application of security updates. Then, detailed logging and
monitoring of all system activities and data access are required for improved
threat detection and response.

##  VI Conclusion

This paper introduced the design solution for the network architecture and the
communication protocols to be used within the TRUSTroke FL platform. The
network design is based on a centralized architecture, with a Parameter Server
hosted at CERN’s premises and the clients running in the clinical nodes’
infrastructures. A Docker-based client design is proposed, which decouples the
communication and data access/processing part for increased privacy and
security. The paper also introduces requirements for the control and data
plane, selecting the MQTT protocol as reference communication protocol for
operating the FL platform and defining a specific control plane to support
such operations. As a final contribution, the paper reports on security
aspects of the proposed design. Future research direction will include the
implementation and testing of the proposed FL platform for stroke prediction
as well as its comparison with existing frameworks for general FL operations.

## References

  * [1] S. AbdulRahman, H. Tout, H. Ould-Slimane, A. Mourad, C. Talhi, and M. Guizani, “A survey on federated learning: The journey from centralized to distributed on-site learning and beyond,” _IEEE Internet of Things Journal_ , vol. 8, no. 7, pp. 5476–5497, 2020.
  * [2] W. Y. B. Lim, N. C. Luong, D. T. Hoang, Y. Jiao, Y.-C. Liang, Q. Yang, D. Niyato, and C. Miao, “Federated learning in mobile edge networks: A comprehensive survey,” _IEEE Communications Surveys & Tutorials_, vol. 22, no. 3, pp. 2031–2063, 2020.
  * [3] V. Mothukuri, R. M. Parizi, S. Pouriyeh, Y. Huang, A. Dehghantanha, and G. Srivastava, “A survey on security and privacy of federated learning,” _Future Generation Computer Systems_ , vol. 115, pp. 619–640, 2021.
  * [4] Trustroke website. [Online]. Available: https://trustroke.eu/
  * [5] B. C. Tedeschini, S. Savazzi, R. Stoklasa, L. Barbieri, I. Stathopoulos, M. Nicoli, and L. Serio, “Decentralized federated learning for healthcare networks: A case study on tumor segmentation,” _IEEE access_ , vol. 10, pp. 8693–8708, 2022.
  * [6] T. Sun, D. Li, and B. Wang, “Decentralized federated averaging,” _IEEE Transactions on Pattern Analysis and Machine Intelligence_ , vol. 45, no. 4, pp. 4289–4301, 2022.
  * [7] J. G. Steiner, B. C. Neuman, and J. I. Schiller, “Kerberos: An authentication service for open network systems.” in _Usenix Winter_ , 1988, pp. 191–202.
  * [8] D. J. Beutel, T. Topal, A. Mathur, X. Qiu, J. Fernandez-Marques, Y. Gao, L. Sani, K. H. Li, T. Parcollet, P. P. B. de Gusmão _et al._ , “Flower: A friendly federated learning research framework,” _arXiv preprint arXiv:2007.14390_ , 2020.
  * [9] G. A. Reina, A. Gruzdev, P. Foley, O. Perepelkina, M. Sharma, I. Davidyuk, I. Trushkin, M. Radionov, A. Mokrov, D. Agapov _et al._ , “Openfl: An open-source framework for federated learning,” _arXiv preprint arXiv:2105.06413_ , 2021.
  * [10] U. Morelli, I. Vaccari, S. Ranise, and E. Cambiaso, “Dos attacks in available mqtt implementations: investigating the impact on brokers and devices, and supported anti-dos protections,” in _Proceedings Of The 16th International Conference On Availability, Reliability And Security_ , 2021, pp. 1–9.
  * [11] W. S. S. Ahamed, P. Zavarsky, and B. Swar, “Security audit of docker container images in cloud architecture,” in _2021 2nd International Conference on Secure Cyber Computing and Communications (ICSCCC)_. IEEE, 2021, pp. 202–207.


University of California, San Diego, La Jolla, USA
J.G. Branson, P. Chang, S. Cittolin, S. Cooperstein, N. Deelen, D. Diaz, J.
Duarte, R. Gerosa, L. Giannini, D. Gilbert, J. Guiang, R. Kansal, V.
Krutelyov, R. Lee, J. Letts, M. Masciovecchio, S. May, M. Pieri, B.V. Sathia
Narayanan, V. Sharma, M. Tadel, A. Vartak, F. Würthwein, Y. Xiang, A. Yagil
University of California, Santa Barbara - Department of Physics, Santa
Barbara, USA
N. Amin, C. Campagnari, M. Citron, A. Dorsett, V. Dutta, J. Incandela, M.
Kilpatrick, J. Kim, B. Marsh, H. Mei, M. Oshiro, M. Quinnan, J. Richman, U.
Sarica, J. Sheplock, D. Stuart, S. Wang California Institute of Technology,
Pasadena, USA
A. Bornheim, O. Cerri, I. Dutta, J.M. Lawhorn, N. Lu, J. Mao, H.B. Newman, J.
Ngadiuba, T.Q. Nguyen, M. Spiropulu, J.R. Vlimant, C. Wang, S. Xie, Z. Zhang,
R.Y. Zhu Carnegie Mellon University, Pittsburgh, USA
J. Alison, S. An, M.B. Andrews, P. Bryant, T. Ferguson, A. Harilal, C. Liu, T.
Mudholkar, M. Paulini, A. Sanchez University of Colorado Boulder, Boulder, USA
J.P. Cumalat, W.T. Ford, A. Hassani, E. MacDonald, R. Patel, A. Perloff, C.
Savard, K. Stenson, K.A. Ulmer, S.R. Wagner Cornell University, Ithaca, USA
J. Alexander, S. Bright-thonney, Y. Cheng, D.J. Cranshaw, S. Hogan, J. Monroy,
J.R. Patterson, D. Quach, J. Reichert, M. Reid, A. Ryd, W. Sun, J. Thom, P.
Wittich, R. Zou Fermi National Accelerator Laboratory, Batavia, USA
M. Albrow, M. Alyari, G. Apollinari, A. Apresyan, A. Apyan, S. Banerjee,
L.A.T. Bauerdick, D. Berry, J. Berryhill, P.C. Bhat, K. Burkett, J.N. Butler,
A. Canepa, G.B. Cerati, H.W.K. Cheung, F. Chlebana, M. Cremonesi, K.F. Di
Petrillo, V.D. Elvira, Y. Feng, J. Freeman, Z. Gecse, L. Gray, D. Green, S.
Grünendahl, O. Gutsche, R.M. Harris, R. Heller, T.C. Herwig, J. Hirschauer, B.
Jayatilaka, S. Jindariani, M. Johnson, U. Joshi, T. Klijnsma, B. Klima, K.H.M.
Kwok, S. Lammel, D. Lincoln, R. Lipton, T. Liu, C. Madrid, K. Maeshima, C.
Mantilla, D. Mason, P. McBride, P. Merkel, S. Mrenna, S. Nahn, V. O’Dell, V.
Papadimitriou, K. Pedro, C. Pena57, O. Prokofyev, F. Ravera, A. Reinsvold
Hall, L. Ristori, B. Schneider, E. Sexton-Kennedy, N. Smith, A. Soha, W.J.
Spalding, L. Spiegel, S. Stoynev, J. Strait, L. Taylor, S. Tkaczyk, N.V. Tran,
L. Uplegger, E.W. Vaandering, H.A. Weber University of Florida, Gainesville,
USA
D. Acosta, P. Avery, D. Bourilkov, L. Cadamuro, V. Cherepanov, F. Errico, R.D.
Field, D. Guerrero, B.M. Joshi, M. Kim, E. Koenig, J. Konigsberg, A. Korytov,
K.H. Lo, K. Matchev, N. Menendez, G. Mitselmakher, A. Muthirakalayil Madhu, N.
Rawal, D. Rosenzweig, S. Rosenzweig, K. Shi, J. Sturdy, J. Wang, E. Yigitbasi,
X. Zuo Florida State University, Tallahassee, USA
T. Adams, A. Askew, R. Habibullah, V. Hagopian, K.F. Johnson, R. Khurana, T.
Kolberg, G. Martinez, H. Prosper, C. Schiber, O. Viazlo, R. Yohay, J. Zhang
Florida Institute of Technology, Melbourne, USA
M.M. Baarmand, S. Butalla, T. Elkafrawy90, M. Hohlmann, R. Kumar Verma, D.
Noonan, M. Rahmani, F. Yumiceva University of Illinois at Chicago (UIC),
Chicago, USA
M.R. Adams, H. Becerril Gonzalez, R. Cavanaugh, X. Chen, S. Dittmer, O.
Evdokimov, C.E. Gerber, D.A. Hangal, D.J. Hofman, A.H. Merrit, C. Mills, G.
Oh, T. Roy, S. Rudrabhatla, M.B. Tonjes, N. Varelas, J. Viinikainen, X. Wang,
Z. Wu, Z. Ye The University of Iowa, Iowa City, USA
M. Alhusseini, K. Dilsiz91, R.P. Gandrajula, O.K. Köseyan, J.-P. Merlo, A.
Mestvirishvili92, J. Nachtman, H. Ogul93, Y. Onel, A. Penzo, C. Snyder, E.
Tiras94 Johns Hopkins University, Baltimore, USA
O. Amram, B. Blumenfeld, L. Corcodilos, J. Davis, M. Eminizer, A.V. Gritsan,
S. Kyriacou, P. Maksimovic, J. Roskes, M. Swartz, T.Á. Vámi The University of
Kansas, Lawrence, USA
A. Abreu, J. Anguiano, C. Baldenegro Barrera, P. Baringer, A. Bean, A.
Bylinkin, Z. Flowers, T. Isidori, S. Khalil, J. King, G. Krintiras, A.
Kropivnitskaya, M. Lazarovits, C. Lindsey, J. Marquez, N. Minafra, M. Murray,
M. Nickel, C. Rogan, C. Royon, R. Salvatico, S. Sanders, E. Schmitz, C. Smith,
J.D. Tapia Takaki, Q. Wang, Z. Warner, J. Williams, G. Wilson Kansas State
University, Manhattan, USA
S. Duric, A. Ivanov, K. Kaadze, D. Kim, Y. Maravin, T. Mitchell, A. Modak, K.
Nam Lawrence Livermore National Laboratory, Livermore, USA
F. Rebassoo, D. Wright University of Maryland, College Park, USA
E. Adams, A. Baden, O. Baron, A. Belloni, S.C. Eno, N.J. Hadley, S. Jabeen,
R.G. Kellogg, T. Koeth, A.C. Mignerey, S. Nabili, M. Seidel, A. Skuja, L.
Wang, K. Wong Massachusetts Institute of Technology, Cambridge, USA
D. Abercrombie, G. Andreassi, R. Bi, S. Brandt, W. Busza, I.A. Cali, Y. Chen,
M. D’Alfonso, J. Eysermans, C. Freer, G. Gomez Ceballos, M. Goncharov, P.
Harris, M. Hu, M. Klute, D. Kovalskyi, J. Krupa, Y.-J. Lee, B. Maier, C.
Mironov, C. Paus, D. Rankin, C. Roland, G. Roland, Z. Shi, G.S.F. Stephans, K.
Tatar, J. Wang, Z. Wang, B. Wyslouch University of Minnesota, Minneapolis, USA
R.M. Chatterjee, A. Evans, P. Hansen, J. Hiltbrand, Sh. Jain, M. Krohn, Y.
Kubota, J. Mans, M. Revering, R. Rusack, R. Saradhy, N. Schroeder, N. Strobbe,
M.A. Wadud University of Nebraska-Lincoln, Lincoln, USA
K. Bloom, M. Bryson, S. Chauhan, D.R. Claes, C. Fangmeier, L. Finco, F. Golf,
C. Joo, I. Kravchenko, M. Musich, I. Reed, J.E. Siado, G.R.
Snow${}^{\textrm{\textdagger}}$, W. Tabb, F. Yan State University of New York
at Buffalo, Buffalo, USA
G. Agarwal, H. Bandyopadhyay, L. Hay, I. Iashvili, A. Kharchilava, C. McLean,
D. Nguyen, J. Pekkanen, S. Rappoccio, A. Williams Northeastern University,
Boston, USA
G. Alverson, E. Barberis, Y. Haddad, A. Hortiangtham, J. Li, G. Madigan, B.
Marzocchi, D.M. Morse, V. Nguyen, T. Orimoto, A. Parker, L. Skinnari, A.
Tishelman-Charny, T. Wamorkar, B. Wang, A. Wisecarver, D. Wood Northwestern
University, Evanston, USA
S. Bhattacharya, J. Bueghly, Z. Chen, A. Gilbert, T. Gunter, K.A. Hahn, Y.
Liu, N. Odell, M.H. Schmitt, M. Velasco University of Notre Dame, Notre Dame,
USA
R. Band, R. Bucci, A. Das, N. Dev, R. Goldouzian, M. Hildreth, K. Hurtado
Anampa, C. Jessop, K. Lannon, J. Lawrence, N. Loukas, D. Lutton, N. Marinelli,
I. Mcalister, T. McCauley, F. Meng, K. Mohrman, Y. Musienko49, R. Ruchti, P.
Siddireddy, A. Townsend, M. Wayne, A. Wightman, M. Wolf, M. Zarucki, L. Zygala
The Ohio State University, Columbus, USA
B. Bylsma, B. Cardwell, L.S. Durkin, B. Francis, C. Hill, M. Nunez Ornelas, K.
Wei, B.L. Winer, B.R. Yates Princeton University, Princeton, USA
F.M. Addesa, B. Bonham, P. Das, G. Dezoort, P. Elmer, A. Frankenthal, B.
Greenberg, N. Haubrich, S. Higginbotham, A. Kalogeropoulos, G. Kopp, S. Kwan,
D. Lange, M.T. Lucchini, D. Marlow, K. Mei, I. Ojalvo, J. Olsen, C. Palmer, D.
Stickland, C. Tully University of Puerto Rico, Mayaguez, USA
S. Malik, S. Norberg Purdue University, West Lafayette, USA
A.S. Bakshi, V.E. Barnes, R. Chawla, S. Das, L. Gutay, M. Jones, A.W. Jung, S.
Karmarkar, M. Liu, G. Negro, N. Neumeister, G. Paspalaki, C.C. Peng, S.
Piperov, A. Purohit, J.F. Schulte, M. Stojanovic15, J. Thieman, F. Wang, R.
Xiao, W. Xie Purdue University Northwest, Hammond, USA
J. Dolen, N. Parashar Rice University, Houston, USA
A. Baty, M. Decaro, S. Dildick, K.M. Ecklund, S. Freed, P. Gardner, F.J.M.
Geurts, A. Kumar, W. Li, B.P. Padley, R. Redjimi, W. Shi, A.G. Stahl Leiton,
S. Yang, L. Zhang, Y. Zhang University of Rochester, Rochester, USA
A. Bodek, P. de Barbaro, R. Demina, J.L. Dulemba, C. Fallon, T. Ferbel, M.
Galanti, A. Garcia-Bellido, O. Hindrichs, A. Khukhunaishvili, E. Ranken, R.
Taus Rutgers, The State University of New Jersey, Piscataway, USA
B. Chiarito, J.P. Chou, A. Gandrakota, Y. Gershtein, E. Halkiadakis, A. Hart,
M. Heindl, O. Karacheban23, I. Laflotte, A. Lath, R. Montalvo, K. Nash, M.
Osherson, S. Salur, S. Schnetzer, S. Somalwar, R. Stone, S.A. Thayil, S.
Thomas, H. Wang University of Tennessee, Knoxville, USA
H. Acharya, A.G. Delannoy, S. Spanier Texas A&M University, College Station,
USA
O. Bouhali95, M. Dalchenko, A. Delgado, R. Eusebi, J. Gilmore, T. Huang, T.
Kamon96, H. Kim, S. Luo, S. Malhotra, R. Mueller, D. Overton, D. Rathjens, A.
Safonov Texas Tech University, Lubbock, USA
N. Akchurin, J. Damgov, V. Hegde, S. Kunori, K. Lamichhane, S.W. Lee, T.
Mengke, S. Muthumuni, T. Peltola, I. Volobouev, Z. Wang, A. Whitbeck
Vanderbilt University, Nashville, USA
E. Appelt, S. Greene, A. Gurrola, W. Johns, A. Melo, H. Ni, K. Padeken, F.
Romeo, P. Sheldon, S. Tuo, J. Velkovska University of Virginia,
Charlottesville, USA
M.W. Arenton, B. Cox, G. Cummings, J. Hakala, R. Hirosky, M. Joyce, A.
Ledovskoy, A. Li, C. Neu, B. Tannenwald, S. White, E. Wolfe Wayne State
University, Detroit, USA
R. Harr, N. Poudyal University of Wisconsin - Madison, Madison, WI, USA
K. Black, T. Bose, J. Buchanan, C. Caillol, S. Dasu, I. De Bruyn, P.
Everaerts, F. Fienga, C. Galloni, H. He, M. Herndon, A. Hervé, U. Hussain, A.
Lanaro, A. Loeliger, R. Loveless, J. Madhusudanan Sreekala, A. Mallampalli, A.
Mohammadi, D. Pinna, A. Savin, V. Shang, V. Sharma, W.H. Smith, D. Teague, S.
Trembath-reichert, W. Vetens †: Deceased
1: Also at TU Wien, Wien, Austria
2: Also at Institute of Basic and Applied Sciences, Faculty of Engineering,
Arab Academy for Science, Technology and Maritime Transport, Alexandria,
Egypt, Alexandria, Egypt
3: Also at Université Libre de Bruxelles, Bruxelles, Belgium
4: Also at Universidade Estadual de Campinas, Campinas, Brazil
5: Also at Federal University of Rio Grande do Sul, Porto Alegre, Brazil
6: Also at University of Chinese Academy of Sciences, Beijing, China
7: Also at Department of Physics, Tsinghua University, Beijing, China,
Beijing, China
8: Also at UFMS, Nova Andradina, Brazil
9: Also at Nanjing Normal University Department of Physics, Nanjing, China
10: Now at The University of Iowa, Iowa City, USA
11: Also at Institute for Theoretical and Experimental Physics named by A.I.
Alikhanov of NRC ‘Kurchatov Institute’, Moscow, Russia
12: Also at Joint Institute for Nuclear Research, Dubna, Russia
13: Also at Cairo University, Cairo, Egypt
14: Also at Zewail City of Science and Technology, Zewail, Egypt
15: Also at Purdue University, West Lafayette, USA
16: Also at Université de Haute Alsace, Mulhouse, France
17: Also at Tbilisi State University, Tbilisi, Georgia
18: Also at Erzincan Binali Yildirim University, Erzincan, Turkey
19: Also at CERN, European Organization for Nuclear Research, Geneva,
Switzerland
20: Also at RWTH Aachen University, III. Physikalisches Institut A, Aachen,
Germany
21: Also at University of Hamburg, Hamburg, Germany
22: Also at Department of Physics, Isfahan University of Technology, Isfahan,
Iran, Isfahan, Iran
23: Also at Brandenburg University of Technology, Cottbus, Germany
24: Also at Skobeltsyn Institute of Nuclear Physics, Lomonosov Moscow State
University, Moscow, Russia
25: Also at Physics Department, Faculty of Science, Assiut University, Assiut,
Egypt
26: Also at Karoly Robert Campus, MATE Institute of Technology, Gyongyos,
Hungary
27: Also at Institute of Physics, University of Debrecen, Debrecen, Hungary,
Debrecen, Hungary
28: Also at Institute of Nuclear Research ATOMKI, Debrecen, Hungary
29: Also at MTA-ELTE Lendület CMS Particle and Nuclear Physics Group, Eötvös
Loránd University, Budapest, Hungary, Budapest, Hungary
30: Also at Wigner Research Centre for Physics, Budapest, Hungary
31: Also at IIT Bhubaneswar, Bhubaneswar, India, Bhubaneswar, India
32: Also at Institute of Physics, Bhubaneswar, India
33: Also at G.H.G. Khalsa College, Punjab, India
34: Also at Shoolini University, Solan, India
35: Also at University of Hyderabad, Hyderabad, India
36: Also at University of Visva-Bharati, Santiniketan, India
37: Also at Indian Institute of Technology (IIT), Mumbai, India
38: Also at Deutsches Elektronen-Synchrotron, Hamburg, Germany
39: Also at Sharif University of Technology, Tehran, Iran
40: Also at Department of Physics, University of Science and Technology of
Mazandaran, Behshahr, Iran
41: Now at INFN Sezione di Bari a, Università di Bari b, Politecnico di Bari
c, Bari, Italy
42: Also at Italian National Agency for New Technologies, Energy and
Sustainable Economic Development, Bologna, Italy
43: Also at Centro Siciliano di Fisica Nucleare e di Struttura Della Materia,
Catania, Italy
44: Also at Università di Napoli ’Federico II’, NAPOLI, Italy
45: Also at Consiglio Nazionale delle Ricerche - Istituto Officina dei
Materiali, PERUGIA, Italy
46: Also at Riga Technical University, Riga, Latvia, Riga, Latvia
47: Also at Consejo Nacional de Ciencia y Tecnología, Mexico City, Mexico
48: Also at IRFU, CEA, Université Paris-Saclay, Gif-sur-Yvette, France
49: Also at Institute for Nuclear Research, Moscow, Russia
50: Now at National Research Nuclear University ’Moscow Engineering Physics
Institute’ (MEPhI), Moscow, Russia
51: Also at Institute of Nuclear Physics of the Uzbekistan Academy of
Sciences, Tashkent, Uzbekistan
52: Also at St. Petersburg State Polytechnical University, St. Petersburg,
Russia
53: Also at University of Florida, Gainesville, USA
54: Also at Imperial College, London, United Kingdom
55: Also at P.N. Lebedev Physical Institute, Moscow, Russia
56: Also at Moscow Institute of Physics and Technology, Moscow, Russia,
Moscow, Russia
57: Also at California Institute of Technology, Pasadena, USA
58: Also at Budker Institute of Nuclear Physics, Novosibirsk, Russia
59: Also at Faculty of Physics, University of Belgrade, Belgrade, Serbia
60: Also at Trincomalee Campus, Eastern University, Sri Lanka, Nilaveli, Sri
Lanka
61: Also at INFN Sezione di Pavia a, Università di Pavia b, Pavia, Italy,
Pavia, Italy
62: Also at National and Kapodistrian University of Athens, Athens, Greece
63: Also at Ecole Polytechnique Fédérale Lausanne, Lausanne, Switzerland
64: Also at Universität Zürich, Zurich, Switzerland
65: Also at Stefan Meyer Institute for Subatomic Physics, Vienna, Austria,
Vienna, Austria
66: Also at Laboratoire d’Annecy-le-Vieux de Physique des Particules,
IN2P3-CNRS, Annecy-le-Vieux, France
67: Also at Şırnak University, Sirnak, Turkey
68: Also at Near East University, Research Center of Experimental Health
Science, Nicosia, Turkey
69: Also at Konya Technical University, Konya, Turkey
70: Also at Istanbul University - Cerrahpasa, Faculty of Engineering,
Istanbul, Turkey
71: Also at Piri Reis University, Istanbul, Turkey
72: Also at Adiyaman University, Adiyaman, Turkey
73: Also at Ozyegin University, Istanbul, Turkey
74: Also at Izmir Institute of Technology, Izmir, Turkey
75: Also at Necmettin Erbakan University, Konya, Turkey
76: Also at Bozok Universitetesi Rektörlügü, Yozgat, Turkey, Yozgat, Turkey
77: Also at Marmara University, Istanbul, Turkey
78: Also at Milli Savunma University, Istanbul, Turkey
79: Also at Kafkas University, Kars, Turkey
80: Also at Istanbul Bilgi University, Istanbul, Turkey
81: Also at Hacettepe University, Ankara, Turkey
82: Also at Rutherford Appleton Laboratory, Didcot, United Kingdom
83: Also at Vrije Universiteit Brussel, Brussel, Belgium
84: Also at School of Physics and Astronomy, University of Southampton,
Southampton, United Kingdom
85: Also at IPPP Durham University, Durham, United Kingdom
86: Also at Monash University, Faculty of Science, Clayton, Australia
87: Also at Università di Torino, TORINO, Italy
88: Also at Bethel University, St. Paul, Minneapolis, USA, St. Paul, USA
89: Also at Karamanoğlu Mehmetbey University, Karaman, Turkey
90: Also at Ain Shams University, Cairo, Egypt
91: Also at Bingol University, Bingol, Turkey
92: Also at Georgian Technical University, Tbilisi, Georgia
93: Also at Sinop University, Sinop, Turkey
94: Also at Erciyes University, KAYSERI, Turkey
95: Also at Texas A&M University at Qatar, Doha, Qatar
96: Also at Kyungpook National University, Daegu, Korea, Daegu, Korea