Support mTLS as an alternative SuperNode authentication mechanism

[yanmxa]

Type

Feature

Description

Flower authenticates SuperNodes using application-layer EC key pair signatures (doc). Each SuperNode signs requests with its private key, and SuperLink verifies using the corresponding public key. In CLI-managed mode, every SuperNode's public key must be individually registered via flwr supernode register.

This is a direct trust model — SuperLink must know every single node's public key upfront:

SuperLink trusts: [PK_node1, PK_node2, PK_node3, ...]
                   ↑ each must be manually registered

This works for small-scale or research setups, but becomes a management burden as the number of nodes grows. Adding or rotating a node always requires a manual registration step on the SuperLink side.

With mTLS, the trust model shifts from "trust each individual key" to "trust the CA that signed the certificates":

Current (direct trust):          mTLS (CA trust chain):

SuperLink stores N public keys   SuperLink trusts 1 CA certificate
         │                                │
    ┌────┼────┐                      ┌────┼────┐
    ▼    ▼    ▼                      ▼    ▼    ▼
  PK_1  PK_2  PK_3               Cert_1 Cert_2 Cert_3
  (each registered               (all signed by the same CA,
   individually)                  no per-node registration needed)

Aspect	Public Key (current)	CA Certificate (mTLS)
Trust model	Trust each key individually	Trust the CA, accept all certs it signed
Adding a node	Must register public key on SuperLink	Just issue a cert from the CA — no SuperLink change
Removing a node	flwr supernode unregister	Revoke the cert (CRL/OCSP)
Key/cert rotation	Generate new key pair + re-register	Reissue cert from CA — transparent to SuperLink
Expiration	Keys never expire	Certificates expire automatically
Identity info	Opaque bytes	Certificate Subject carries org name, node ID, etc.

I'd like to propose supporting mTLS as an optional authentication mode alongside the existing EC key pair mechanism (TLS doc, auth doc).

Planned Implementation

By default, a single CA can serve both purposes — verifying SuperLink's server certificate and verifying SuperNode/CLI client certificates. The --ssl-ca-certfile already points to this CA; with mTLS enabled it would also be used to verify client certificates. For cases where server and client certificates are issued by different CAs (e.g., SuperLink uses a public CA while SuperNodes use an internal CA), an optional --ssl-client-ca-certfile could override the client CA independently.

SuperLink — add --ssl-require-client-auth to enable mutual authentication:

flower-superlink \
    --ssl-ca-certfile certificates/ca.crt \        # by default, also verifies client certs
    --ssl-certfile certificates/server.pem \
    --ssl-keyfile certificates/server.key \
    --ssl-require-client-auth                       # NEW: require client certs signed by ca.crt
    # --ssl-client-ca-certfile certificates/client-ca.crt  # OPTIONAL: use a separate CA for client certs

When --ssl-require-client-auth is enabled, SuperLink verifies client certificates at the TLS handshake layer. No --enable-supernode-auth or flwr supernode register is needed — any SuperNode or CLI presenting a certificate signed by the trusted CA is accepted.

SuperNode — add client cert flags for SuperNode's own identity:

flower-supernode \
    --root-certificates certificates/ca.crt \       # verifies SuperLink (unchanged)
    --ssl-client-certfile certificates/node-1.pem \  # NEW: client certificate (signed by the CA)
    --ssl-client-keyfile certificates/node-1.key \   # NEW: client private key
    --superlink 192.168.1.100:9092

When client cert flags are provided, the SuperNode presents its certificate during the TLS handshake. No --auth-supernode-private-key or application-layer NodeAuthClientInterceptor signing is needed.

Flower CLI (flwr run) — if SuperLink requires client auth, the CLI also needs a client certificate. This can be configured in config.toml:

[superlink.my-deployment]
address = "192.168.1.100:9093"
root-certificates = "/path/to/certificates/ca.crt"
client-certificate = "/path/to/certificates/cli.pem"   # NEW
client-private-key = "/path/to/certificates/cli.key"    # NEW

gRPC Python natively supports mTLS via grpc.ssl_server_credentials(require_client_auth=True) and grpc.ssl_channel_credentials(certificate_chain, private_key) (gRPC auth guide). The existing EC key pair auth remains the default for backward compatibility.

Additional Context

We are deploying Flower on Kubernetes/OpenShift where platform-specific certificate controllers (e.g., cert-manager, service-ca) handle the full certificate lifecycle (issue, rotate, revoke) automatically. Supporting mTLS would allow Flower to integrate naturally with these existing certificate management systems, while also simplifying the current authentication workflow by eliminating the need for manual flwr supernode register and per-node public key management.

I'm happy to contribute an implementation if the direction is agreed upon.

[WilliamLindskog]

Thanks for opening this issue @yanmxa !

I'll take a look at it this week.

[rwilliamspbg-ops]

Great proposal @yanmxa. Moving toward a CA-based trust model is a huge step for scalability, but we can take this further to address Post-Quantum Cryptography (PQC) and hardware-level identity—especially for sensitive federated learning workloads.

I’ve been working on the Sovereign-Mohawk-Proto (SMP), which implements a PQC-Hardened Wrapper that could resolve several of the "management burdens" mentioned in this thread while future-proofing the stack.

How SMP could evolve this mTLS proposal:

TPM-Anchored Identity: Instead of relying on software-managed certificates that can be exfiltrated, SMP utilizes TPM 2.0 attestation. This ensures that the "SuperNode" is not just a valid certificate holder, but a verified, physical piece of hardware.

Hybrid PQC Key Exchange: While mTLS often relies on classical ECC/RSA, SMP implements a hybrid path using ML-KEM-768 and XMSS. This protects the SuperLink/SuperNode handshake against "harvest now, decrypt later" attacks.

Zero-Knowledge Verification: By integrating SMP’s zk-SNARK verification path, we can achieve sub-11ms attestation times, which aligns perfectly with the low-latency requirements of Flower’s SuperLink.

Implementation Synergy:
The existing grpc.ssl_server_credentials logic mentioned in the Planned Implementation can be extended to support SMP’s hybrid transport mode (MOHAWK_TRANSPORT_KEX_MODE). This would allow Flower to support standard mTLS for legacy environments while offering a "High-Security" tier for PQC-compliant nodes.

I'd be happy to contribute a technical RFC or a proof-of-concept showing how the SMP Python SDK can wrap these SuperNode connections.

Thoughts on making PQC/Hardware-attestation an optional "Hardened Mode" for this feature?