Understanding the authentication security of CLARA FL client and admin

Hi devs & users of CLARA - hope you are well.
I have a question re: the authentication security for a CLARA FL client and admin user.

From the documentation and our test runs, it seems like for a training client or for a FL admin user to connect to the FL server, it just needs to:

  1. Use the corresponding provisioning package generated by the provisioning package generation tool
  2. Authenticate with the email address entered when the provisioning package was generated

In addition these, is there anything that acts like a “password” or “unique key” in each provisioning package that is difficult to reproduce by a different client that would prevent someone else from connecting to the server “on behalf” of another client?

To put this question in another way: if someone has a good understanding of what is required in the provisioning package and is aware of the “publicly available” information of the server and the client (e.g. server and client IPs, client email address, some non-confidential server settings, etc), is it possible for this person to “recreate” a working provisioning package and connect to the server using an email address that does not belong to him/her?
Or does the provisioning package for each client and admin user contain some kind of a unique “password” or “key” that is being loaded and validated when a client attempts to connect to the server? If so, what file is that? And if not, what is the security consideration for not utilizing a “password” for client-server or admin-server connection without concerns for potential hacking?

Thanks for your help!

Andy

Hi
Thanks for your interest in Clara Train SDK. I reached out to engineering and they had the following explanation

NVFlare uses the self-signed SSL certificates to build the identity trust between the server and client / admin. The server, client and admin each has its own SSL certificate which can only be trusted between themselves. If any of them got compromised, the communicate channel will be set up correctly. The secure communicate channel are set up through the two-way SSL certificates trust. The certificates are stored in the files like “server.crt”, “server.key”, and “rootCA.pem”. All these SSL certificates, private keys, etc, are generated by the provision tool, not through the public channel.

Hope this helps

Thank you aharouni for the clarification. That makes sense.
So basically the certificate files of the clients are the key elements that are used to authenticate the client, and each client should be aware of not exposing them and should treat them as a password.
Sounds good. Thanks!