Methods and systems for federated learning

Abstract

Disclosed is a method for updating a federated learning (FL) model over one or more iterations. Each iteration involves transmitting hyper-parameters of the FL model from a server to all clients. Each client then generates a respective model update (hyper-parameter updates) based on private information, a commitment and secret share. Model updates are transmitted to the server and the secret shares are shared between clients. Client verify received secret shares using a zero-knowledge proof, with invalid secret shares resulting in sending client being marked as malicious. The server performs a probabilistic integrity check on the commitments and filters out commitments from any malicious clients. Each client also sends to the server an aggregate of its secret share and any received secret shares from honest clients. The server then reconstructs a sum of honest client secret shares, aggregating the corresponding honest client updates to update the FL model.

Description

[0001] METHODS AND SYSTEMS FOR FEDERATED LEARNING

[0002] Technical Field

[0003] The present disclosure relates to systems and methods for federated learning. More particularly, the invention relates to, but is not limited to, federated learning employing computationally efficient methodology that ensures input privacy and input integrity of participating clients.

[0004] Background

[0005] This background description is provided for the purpose of generally presenting the context of the disclosure. Contents of this background section are neither expressly nor impliedly admitted as prior art against the present disclosure.

[0006] Organizations are increasingly recognizing the value of data collaboration for data analytics purposes. Stringent data protection laws prohibit the direct exchange of raw data. To facilitate data collaboration, federated Learning (FL) has emerged as a viable solution, enabling multiple clients to collaboratively train a machine learning (ML) model under the supervision of a central server while ensuring raw data confidentiality.

[0007] Existing FL methodologies are exposed to two main risks: (i) the potential for the server to infer sensitive information from the client's uploaded updates (i.e., model gradients), compromising client input privacy, and (ii) the risk of malicious clients uploading malformed updates to poison the FL model, compromising input integrity. For example, in one scenario there exists a set of malicious clients that aim to poison the collaboratively trained model via Byzantine attacks, such as imposing backdoors so that the model is susceptible to specific input data, contaminating the training process with malformed updates to degrade model accuracy, and so on. To protect input privacy, instead of uploading the plaintext local updates to the server, clients can utilize secure aggregation techniques. Such techniques, which include secret sharing and homomorphic encryption, mask or encrypt the local updates so that the server can aggregate the clients' updates correctly without knowing each update. In this way, the client's input privacy is preserved. These solutions do not ensure input integrity because it is difficult to distinguish malicious encrypted updates from benign ones. To protect input integrity, some Byzantine-robust aggregation algorithms allow the server to identify malformed updates and prevent them from being aggregated into the global update. Nevertheless, these algorithms require the clients to send plaintext updates to the server for integrity verification, compromising the client's input privacy.

[0008] An alternative methodology uses secure aggregation to protect each client's update and allow the server to check the encrypted update's integrity using zero-knowledge proof (ZKP) protocols. The general idea is to let each client compute a commitment of its local update and generate a proof that the update satisfies a publicly-known predicate is within a specific range. The server can then verify the correctness of the proofs based on the commitments and securely aggregate the valid updates without the need of knowing the plaintext values. Unfortunately, these solutions suffer from extremely low efficiency in proof generation and verification, making them impractical for real deployments.

[0009] It is hence desirable to provide a computationally efficiency FL method that ensures input privacy and integrity, and at least provides a viable alternative to known methodologies.

[0010] Summary

[0011] Proposed herein is an efficient approach, referred to as RiseFL in some contexts, for secure and verifiable data collaboration, simultaneously ensuring input privacy and integrity. Firstly, a probabilistic integrity check method is used to transform strict checks into a hypothesis test problem. Secondly, a hybrid commitment scheme is used to satisfy Byzantine robustness with improved performance. Thirdly, an optimized ZKP generation and verification technique is employed to significantly reduce the ZKP cost based on probabilistic integrity checks.

[0012] Disclosed is a method for updating a federated learning (FL) model, using a server and a plurality of clients, comprising, for each of one or more iterations: transmitting hyper-parameters for the FL model from the server to all clients; each client: generating a respective model update comprising updates to the hyper-parameters, based on private information of the respective client, and generating a respective commitment and secret share corresponding to the model update; transmitting the commitment to the server; and sharing the secret share with one or more other said clients; each client that receives a secret share from another said client verifying the received secret share using a zero-knowledge proof, and marking the another said client as malicious if the secret share is invalid; the server performing a probabilistic integrity check on the commitments and filtering out commitments from any client marked as malicious, any client not marked as malicious being an honest client; each client sending to the server an aggregate of the secret share generated by the respective client and any received secret shares from honest clients; and the server reconstructing a sum of the secret shares from honest clients, aggregating the corresponding updates from the honest clients to update the FL model.

[0013] Also disclosed is a computer system for updating a federated learning (FL) model, comprising: memory; at least one processor; a server; and a plurality of clients, the memory storing instructions that, when executed by the one or more processors, cause the system to: transmit hyper-parameters for the FL model from the server to all clients; each client: generating a respective model update comprising updates to the hyper-parameters, based on private information of the respective client, and generating a respective commitment and secret share corresponding to the model update; transmitting the commitment to the server; and sharing the secret share with one or more other said clients; each client that receives a secret share from another said client verifying the received secret share using a zero-knowledge proof, and marking the another said client as malicious if the secret share is invalid; perform, at the server, a probabilistic integrity check on the commitments and filtering out commitments from any client marked as malicious, any client not marked as malicious being an honest client; each client sending to the server an aggregate of the secret share generated by the respective client and any received secret shares from honest clients; and reconstructing, at the server, a sum of the secret shares from honest clients, aggregating the corresponding updates from the honest clients to update the FL model.

[0014] Brief description of the drawings

[0015] Some embodiments of the present invention, in accordance with the present disclosure, will now be described, by way of non-limiting example only, with reference to the accompanying drawings in which:

[0016] Figure 1 is an overview of a FL model updating process in accordance with present teachings.

[0017] Figure 2 illustrates a probabilistic check when ||u||2= 1.

[0018] Figure 3 schematically illustrates a system for performing the process of Figure 1.

[0019] Detailed description

[0020] Described herein is a practical FL system that ensures both input privacy and input integrity. Some embodiments focus on the i2-norm integrity check. In this implementation, the L2-norm is that a client's local update is less than a threshold. Present approaches provide a number of key features. First, a probabilistic t2-norm check method transforms the strict i2-norm check into a Chi-square hypothesis test. The rationale is to sample a set of public vectors and let each client prove that the summation of the inner products between its update and the public vectors is bounded, instead of directly checking the £2-norm of the update. This transformation facilitates the development of optimization techniques to reduce the complexity. Second, a hybrid commitment scheme is used, based on Pedersen commitment and verifiable Shamir secret sharing commitment, tailored for the probabilistic check method. It not only ensures Byzantine robustness but also achieves notable performance improvement on the client computation. Third, an optimized ZKP generation and verification technique is implemented by merging the common group exponentiations across the clients for the probabilistic check method. This reduces the cryptographic operation cost of proof generation and verification from o(d) to o(d / logrf). The presently proposed approach can be easily extended to various Byzantine-robust integrity checks based on different f2-norm variants, such as cosine similarity, sphere defense, and Zeno+ + .

[0021] In the model system, there are n clients {Ci, and a centralized server in the system. In other embodiments, a decentralized or distributed server may be used. Each client Ci(i e [n]) holds a private dataset Mo participate in data collaboration for training a federated learning (FL) model M. Let d be the number of parameters in M. In each iteration, the FL training process consists of three phases. Firstly, the server broadcasts the current model parameters to all the clients. Secondly, each client Ci computes a local update ui (i.e., model gradients) given the model parameters and its dataset Di , and submits u,to the server. Thirdly, the server aggregates the clients' gradients to a global update u = £,e[n]u,and updates the model parameters of M for the next round of training until convergence.

[0022] The system is subjected to a malicious threat model in two aspects. First, regarding input privacy, a malicious server (i.e., the adversary) is assumed that can deviate arbitrarily from the specified protocol to infer each client's uploaded model update. Also, the server may collude with some of the malicious clients to compromise the honest clients' privacy. Since a malicious server would endeavour to access data rather than corrupt it, it is assumed that the server is not malicious against the input integrity because. Second, regarding input integrity, it is assumed that there are at most m malicious clients in the system, where m < n / 2. The malicious clients can also deviate from the specified protocol arbitrarily, such as sending malformed updates to the server to poison the aggregation of the global update, or intentionally marking an honest client as malicious to interfere with the server's decision on the list of malicious clients.

[0023] To ensure both input privacy (for the clients) and input integrity (for the server) under the proposed threat model, the problem is formulated as a relaxed variant of secure aggregation with verified inputs (SAVI), namely (D, F)-relaxed SAVI, with the definition set out below, (D, F)-relaxed SAVI maintains input privacy while relaxing the input integrity for significant efficiency improvement.

[0024] Given a security parameter K, a function D: -» IR satisfying that u is malicious if and only if D(u) > 1, a function F ; (l, + oo) [0, 1], a set of inputs {ui, -,u„} from clients c = {Ci, . . . , e„} respectively, and a list of honest clients Cn, a protocol n is a (D, F)-relaxed SAVI protocol for CH if:

[0025] • Input Privacy. The protocol n realizes the ideal functionality 7'such that for an adversary that consists of the malicious server and the malicious clients e \ cHattacking the real interaction, there exist a simulator s attacking the ideal interaction, and

[0026] • Input Integrity. The protocol n outputs tcval Ju, with probability of at least 1 - negl(K), where Cvaiid is the set of clients that pass the integrity check and CH £ Cvaiid. For any malformed input U; from a malicious client Cj, the probability that it passes the integrity check satisfies:

[0027] Pr[e7e cVaHd] < F (D(W7))

[0028] In the above definition, the server can only learn the aggregation of honest clients' updates. This definition also relaxes the integrity verification by introducing a malicious pass rate function F. F is a function that maps the degree of maliciousness of an input to the pass rate of the input, and the degree of maliciousness is measured by the function D. For instance, with an L2-norm bound B, a natural choice of D is B(W) = ||U||2 / B, and the pass rate of a malicious u is F (D(U)).

[0029] Intuitively, the higher the degree of maliciousness, the lower the pass rate. So, F is usually decreasing. Our system also satisfies lim sup. ,+«. F(%) < negl(K). When F = neg I ( / <■), a protocol that satisfies (D, F)-relaxed SAVI will also satisfy SAVI. A method 100 satisfying the above definition is schematically reflected in Figure 1. The method 100 updates a federated learning (FL) model, using a server 102 and a plurality of clients (Client 1, Client 2 and Client 3). The FL model is initialized (image (a)) and iteratively updated, with each iteration involving comprising committing a model update and secret share (image (b)), proof generation and verification (image (c)) and secure aggregation (image (d)).

[0030] To method 100 endeavours to solve the problem in Definition 1, using a methodology that tolerates a predetermined number of malicious clients for input integrity. With the predetermined number m < n / 2, the server can securely aggregate the clients' inputs as long as a majority of the clients are honest. In the initialization stage (Figure 1, image (a)), the server transmits hyper-parameters for the FL model from the server to all clients. As such all the parties agree on some hyper-parameters, such as the number of clients n, the maximum number of malicious clients m, the security parameters, e.g., key size and others. In some embodiments, the parties also agree on the bound on the number of bits hip of each inner product, the maximum number of bits bmax > &ip of the sum of squares of inner products, the bound of the sum of discretizing the normal distribution samples, and a cryptographic hash function / / (■)■ hip and bmax set the bounds of {a^ u} and in Equation (1), respectively.

[0031] Following from initialisation, in each iteration of the FL training process, each client generates a respective model update comprising updates to the hyper-parameters, based on private information of the respective client (e.g., patient data), and generates a respective commitment and secret share corresponding to the model update. Each client Ci (i e [n]) commits its model update ui using the hybrid commitment scheme. The hybrid commitment scheme involves generating commitments (and later aggregating updates) using an additively homomorphic commitment scheme, such as Pedersen Commitment.

[0032] In relation to Pedersen Commitment, let G denote a cyclic group with prime order p, where the discrete logarithm problem is hard. Let Z,, denote the set of integers modulo the prime p and x, x, and X denote a scalar, a vector, and a matrix, respectively, Enck(x) denotes an encrypted value of x under an encryption key K, and Deci<(y) denotes a decrypted value of y under the same key K. Since the data used in ML are often floating-point values, fixed-point integer representations are used to encode floating-point values.

[0033] The present homomorphic commitment scheme, Pedersen Commitment, is a cryptographic primitive that allows one to commit a chosen value without revealing the value to others while still allowing the ability to disclose it later. In the Pedersen commitment embodiments, a party commits its secret value Given independent group elements (y, h), the party generates a random number r e Zpand values can be securely aggregated without being revealed.

[0034] As mentioned above, each client generates a secret share corresponding to the update u>. In some embodiments, the secret shares are generated and verified according to an additively homomorphic sharing scheme, such as Shamir's Secret Sharing Scheme. Under this t-out-of-n secret sharing (SSS) scheme a party can distribute a secret among a group of n parties via shares so that the secret can be reconstructed given any t shares but cannot be revealed given less than t shares. The SSS scheme is verifiable (aka. VSSS) if auxiliary information is provided to verify the validity of the secret shares. The VSSS scheme is used to share a number r e ZP. Specifically, the VSSS scheme consists of three algorithms, namely, SS. Share, SS. Verify, and SS. Recover. algorithm recovers the secret r. • True / False <- SS. Verify (lP, i,rl,n,t,g). Given a share (i, n) and the check string % it verifies the validity of this share so that it outputs True if (i, n) was indeed generated by SS.Share(r, n, t, g) and False otherwise.

[0035] This scheme is additively homomorphic in both the shares and the check string. If ) ,

[0036] While the clients send secret shares to each other, in some applications, such as when hospitals are contributing patient data, the clients (hospitals) do not directly communicate. The present methodologies envisage a malicious server, where the server must forward some messages between clients. To protect against a malicious server, each client Ci (i e [n]) generates a public / private key pair (pfa, ski) and sends the public key pk, to a public bulletin. Subsequently, each client fetches the other clients' public keys such that each pair of clients can establish a secure channel via the Diffie-Hellman protocol for exchanging messages securely.

[0037] The above commitment scheme and secret sharing scheme enable use of ZKPs, allowing a prover to prove to a verifier that a given statement is true, such as a value is within a range, without disclosing any additional information to the verifier. Two additively homomorphic ZKP protocols are selected based on the Pedersen commitment as building blocks. The ZKP may exploit mathematical relationships between secrets and independent elements, to verify integrity of the input without knowledge of the input itself. The first is the Z-protocol for proof of square and proof of relation. For proof of square ((x, n, r2),(yi,y2)), denote (g, h) as the independent group elements, and let yi = C(x, n) and yz = C(xz, n) be the Pedersen commitments, where x, n, n e ZPare the secrets. The function GenPrfSq((x, n, n), (yi.yz)) generates a proof n that the secret value in y? is the square of the secret value in yi. Accordingly, the function VerPrfSq(7r,yi,y2) verifies the correctness of this proof. Similarly, for proof of a relation ((r, v, s),(z, e, o)), denote (g, q, h) as the independent group elements, and let z = gr,e = gvhr,o = gvqsbe the Pedersen commitments, where r,v,s e z., are the secrets. The function GenPrfBd(x, y,r,b) generates a proof n that the secrets in e and o are equal, and the secret in z is equal to the blind in e. The function VerPrfWf(?r, z, e, o) verifies the proof. The second ZKP protocol used is a short, non-interactive zero-knowledge proof, such as the Bulletproofs protocol, for checking the bound of a value x with its Pedersen commitment y = c(x, r). GenPrfBd(.r,y, r, b) denotes the function that generates a proof n that ;< £ (0, 26), where 26is the bound to be ensured. The corresponding function VerPrfBd(7r,y, b) verifies the proof.

[0038] In some embodiments, these building blocks are extended to the vector form such that the proof generation and verification execute on a batch of values.

[0039] Thus, in Figure 1, image (b), each iteration of the FL training process (i.e., the process for training the FL model), each client mmits its model update Ui. In some embodiments, this will use the hybrid commitment scheme based on Pedersen commitment and verifiable Shamir's secret sharing (VSSS) mentioned above. Each client then transmits the commitment to the server and the secret shares to the one or more, and potentially all, other clients.

[0040] In order to prove to the server that the L2-norm of u< is within a bound Bo, the client Ct needs to commit its update ui before generating the proofs. The server is expected to not only identify malicious clients, but also aggregate well-formed model updates so that the training process is not affected by malicious clients. The hybrid commitment scheme developed for this purpose protects the random secret in the Pedersen commitment. Relevantly, that the clients and server agree on independent group elements g, wt, wde G, where wf(j e [d]) is used for committing the jthcoordinate in u,. Then, e, generates a random secret n e ZPand encrypts u,: with Pedersen commitment as follows: where uy is the ythcoordinate in Ui. Each client Ci sends y, = C(Ui, n) and zt= gTito the server as commitments. Given that n is held by each client &, the server knows nothing regarding each update Ui. To facilitate the server to aggregate well-formed updates, each client e< is required to share its secret n with other clients using VSSS. Specifically, Ci computes ((l,r,i), ..., (71,^),^.) <- SS.Share(n, n,m + 1, g) and sends to Cj - thus, the equality % / ()) = z;holds. Since the clients do not have communication channels, e<encrypts each share ny with the corresponding symmetric key established by (pfcy , sfc,) for each client Cj(j& [n]) obtaining Enc(ny). The encrypted Enc(n,) ensures that only r’- can decrypt it. Finally, Ci sends the commitment yt, the encrypted share Enc(ri;)C / e [n]), and the check string >Pr. to the server.

[0041] With reference to Figure 1, image (b), in one example Client 2 has a model update U2 = (5, 1) and its generates a random secret r? = 10. Let wi = g3and wi = g*. encrypted using keys shared with Client 1 and Client 3 respectively before they are sent to the server together with the check string. For the equation 4VJ0) = zz, both sides equal g10.

[0042] After receiving the messages from all clients, the server forwards the encrypted shares Enc(ny)(i e [n]) to client Cj, and broadcasts the check strings ^ (i e [n]) to all clients.

[0043] In the proof generation and verification round (Figure 1, image (c)), the clients and the server jointly flag the malicious clients. To achieve this, there are two steps. In the first step, each client verifies the authenticity of other clients' secret shares. Thus, each client that receives a secret share from another said client verifies the received secret share, to determine whether the sender is malicious or honest. For the secret shares that are verified to be invalid, the client marks the respective clients as malicious. With the marks from all clients, the server can then identify a subset of malicious clients - all other clients are considered honest. In the second step, the server performs a probabilistic integrity check on the commitments (i.e., each client's update Ui) and filters out commitments from any client marked as malicious. Next, the server filters out the malicious client list and broadcasts it to all the clients.

[0044] The server initializes a list f = 0 to record the malicious clients that will be identified in the current iteration. This round consists of two steps: verifying the authenticity of secret shares and verifying the integrity of each client's update.

[0045] To compose the list of malicious clients for each iteration, the method 100 involves transmitting a maximum number m of malicious clients from the server to each client. Thus, all parties are in agreement as to the maximum number of malicious parties. Each client marks other clients as malicious by adding them to a respective set of malicious clients and transmitting the set to the server - the set may be empty (NULL) or comprise any number of malicious parties between 0 and m. If a number of malicious clients in the respective set is at most m, the malicious clients from the respective set are added to the list maintained by the server. If the number of malicious clients in the respective set exceeds m, the client that sent the set is added to the list of malicious clients. Moreover, to identify malicious clients that attempt to mark honest clients' contributions as malicious, further steps can be performed. In particular, if a client is marked as malicious by at most tn other said clients, the server verifies each secret share that the client sent to the other clients. If any of those secret shares is found invalid, the client is added to the list of malicious clients. Specifically, after receiving the encrypted shares Enc(rj,) and check strings MJr7for j e [n] each client Ct decrypts r7iand checks against MA-j. If a check fails. Ct marks the corresponding client Cj as malicious because the share is not authenticated. Subsequently, Ci posts the list of clients that do not pass the check on the public bulletin board. If a client G flags more than m clients as malicious or is flagged as malicious by more than m clients, the server puts Gto G. This is because there are at most m malicious clients in the system. An honest client cannot mark more than m clients as malicious clients and will not be marked as malicious by more than m clients. For example, in Figure 1, image (c), if Client 3 marks the other two clients as malicious, then the server can ensure that this client is malicious.

[0046] Second, if a client Ct is flagged as malicious by [l,m] clients, it sends the shares n, to the server in the clear for all Gthat flags Ct. The server then checks them against HA-i. If any of the clear fails the check, the server puts Ct to c*. Note that any client that marks an honest G as malicious must be malicious. If client Ct reads from the public bulletin board that more than m clients mark G as malicious, it quits the protocol because this should not happen. Thus, for each secret share found to be valid the party (client) that marked the client as malicious is added to the list of malicious clients, since it has attempted to mark an honest party as malicious.

[0047] The server and clients then jointly execute a probabilistic integrity check on the commitments and filter out commitments from any client marked as malicious, any client not marked as malicious being an honest client. Without loss of generality, the check will be described for one client G. In some embodiments, the probabilistic integrity check is intended to reduce the complexity of expensive group exponentiations used in other methods. To do so, a probabilistic L2-norm bound check method is developed as set out in Algorithm 1, below.

[0048] Input: u e Kd,B,fc,e

[0049] Output: "Pass" or "Fail"

[0050] 1 Sample a,, ... , ake R'' i.i.d. from JV(O, id)

[0051] 2 Compute yk ewhich satisfies that Prt~rfc[t < nJ = 1 - e then

[0052] 4 return "Pass"

[0053] 5 else

[0054] 6 | return "Fail"

[0055] 7 end

[0056] Algorithm 1: probabilistic L2-norm bound check

[0057] The intuition is that, instead of generating and verifying proofs for the L2-norm of an update ||u||z, where u e Kd, k points ai, . . . ,a- can be randomly sampled from the normal distribution J\r(o,id). Then, the random variable: follows a Chi-square distribution xl with k degrees of freedom. In Algorithm 1, if ||u||2< B, then the probability that u passes the check is at least 1 - e, where e is chosen to be cryptographically small, e.g., 2-128. In this way, the probability that the client fails the check is of the same order as the probability that the client's encryption is broken.

[0058] Figure 2 shows an example of this method. Assume that ||u||2= 1. Two random normal samples ai, a2 are taken. Then, the inner products (a2, u) are the projections of ai, a? onto u. Figure 2, image (b) gives the probability density function of Xk-With the specific bound as computed in Algorithm 1, there is an overwhelming probability such that St=i (af «)2< n.e-

[0059] The probabilistic check method does not directly reduce complexity, as the ZKP proof with respect to (at,u)2is still dependent on d. Nevertheless, this method affords optimizations. In particular, the hybrid commitment scheme reduces overall complexity by a factor of O(m) compared to known method, EIFFeL. Moreover, as discussed below, the optimized ZKP generation and verification technique carefully merges common group elements across clients required for each sample vector in the probabilistic test, achieving a cost reduction by a factor of o(logd) compared to EIFFeL.

[0060] Implementing the probabilistic integrity check in Figure 1, image (c), k random vectors are sampled. At the beginning, the server and clients need to agree on fc random samples ai,"-,ai< with dimensionality d. In some embodiments, the server samples the k vectors and broadcasts them to all clients. However, under this method the communication cost can be very high since it is communication inefficient for the server to broadcast k vectors (each vector contains d elements). Also, the server may select special vectors that are not random, i.e., the vectors may allow the server to infer the client's update easily. For example, if the server selects for all t e [ / <■] it may infer the range of the first element in a client's update. To solve these issues, in some embodiments the server selects a random value sand broadcast it to all clients. Based on s, the server and each client ef(i e [n]) can compute a seed H(s,{pkl}l <i <n), a hash function, using s and all clients' public keys. Hence, the clients and the server can generate the same set of random samples because the seed is the same. Note it is computationally infeasible to find a seed that produces specific vectors since / / (■) is a cryptographic hash function.

[0061] As mentioned above, to further increase computational efficiency, groups elements are merged. Given the random vectors ai,— ,a*, a naive way of realizing the ound check in Algorithm 1 is to let client Ci commit to (aL,ut} with zL= e [fc] based on additional independent group elements m+i, . . . , wi+k. It can then generate a ^-protocol proof that the secret in ztis indeed the inner product of the secrets in y, and atfor t e [fc] and a proof that the sum of the squares of the secrets in zfis bounded. However, its computational cost will be o(d) in terms of group exponentiations. By merging group elements the cost of proof generation is reduced to o(d / log.<) group exponentiations.

[0062] We observe that the following term et(t e [fc]) is used in the inner product proof generation and verification: where y(i,- -,yware the commitments of elements in ui (see Equation (1)). The group elements wi,..., w^ are then merged into ht= w;“t1...wdtd, which is the same for all the clients as the random vector atand the group elements wi,-, wdare shared by the server and clients.

[0063] The server can thus precompute the merged htfor t e [fc]) and broadcast them to all clients before they generate proofs. Given ht, the cost of computing the values etin Equation (3) for t e [fc] is o(fc) group exponentiations and o ( / <.,) finite field operations. Still, the client cannot blindly compute the value in Equation (3) by et= as htis received from the server, which could be malicious. Therefore, the client uses batch verification to check whether the merged elements ht for t e [fc] are computed correctly. The cost of batch verification is O(d / log<i) group exponentiations and O(ku) finite field operations. The group exponentiations are the major cost - so, the reduction of the number of group exponentiations from 0(d) to O(d / logd) significantly reduces client cost, while the additional cost of o(fe) finite field operations is not large.

[0064] To make sure that etis indeed the commitment of the inner product of atand the secret in y(, the server uses batch verification to check that the values et, t e [k], cryptographically secure pseudo-random number generator (PRNG), computes the corresponding h0= n[wia" and broadcasts it together with hi,..., hk. The client needs to additionally verify the correctness of ho together with hi,..., hk by batch verification. The server then uses batch verification in Algorithm 2 to check the correctness of

[0065] Input: w = (w1;. wd) A e M((£+1)xd(

[0066] 1 Randomly Sample b

[0067] 2 Compute c = (cj cd

[0068] 3 return ... hkk= wf1

[0069] Algorithm 2:

[0070] With the additional commitment eo, the server can acquire an additional S-protocol proof that client efpossesses a value y that satisfies e0= grhr0‘ . Once this additional proof is satisfied, the server is sure that client c,- possesses u.-that satisfies yu= g^'w,1and that y = {a0,Ui}. Therefore, the secrets in etare indeed the inner product between atand ut, te {0,---, k}.

[0071] Finally, the commitment etuses group element ht, which is different for different t. In order to verify the bound of the sum of the squares of the secrets in et, another independent group element q must be fixed and et must be converted to another commitment o£= g^^q^, where stis another blind chosen by client Ci. ot, t e [fc] are all based on q. The bound of the squares of the secrets can then be checked in ot.

[0072] With further reference to Algorithm 1, the probabilistic input integrity verification will now be described. Assume the server and clients generate k +1 random samples A = (ao, al, -•-, afc) e zdu sing the aforementioned techniques. After that, the server computes ht= nJw“f' for t e {(),-, kJ. Let h = The server sends h to the client. Upon receiving the information, the client first verifies the correctness of h using VerCrt(w,h,A) in Algorithm 2. If it is correct, the client computes the following items for generating the proof that Equation (2) is less than the bound Bo.

[0073] • The client computes the inner products between u> and each row of A, obtaining v = (vo, vi,---, vk}, where vt{aL,ui) for t e {0, -•-, k}. The client commits ei = g"‘hy using its secret nfor t e {O, -, / <}. Let e* = (e0, el, --, et) and e = (ei, -•-, e*). The commitment eo is used for integrity check of y(. The commitments e are used for bound check of v = (vi, -•-, w,).

[0074] • The client commits vtusing ot= gVtqStfor t e [fc] where sfis a random number. Let o = (oi,-, ok} be the resulted commitment. Note that etand otcommit to the same secret vtusing different group elements ht and q. • The client generates a proof p to prove that (z, e-, o) is well-formed, which means that the secret in z is used as the blind in et, te {0,--, k}, and that the secrets in etand oi are equal, t e [fc]. Note that z= is the 0thcoordinate of the check string of Shamir's share of n.

[0075] • The client generates a proof a that the secret in otis in the interval [-26ip , 26'P ) for t e [fc]. This ensures the inner product of atand Ui does not cause overflow when squared probabilistic check.

[0076] Finally, the client sends the proof n = (e:, o, o', p, r, tr, p) to the server for verification. After receiving the proof, the server verifies it accordingly, including checking the correctness of e* using Algorithm 2, checking the well-formedness proof / ?, checking the square proofs of (o',o), and checking the two bound proofs. If all the checks are passed, the server guarantees that the client's update passes the probabilistic check in the single iteration of the present method, as reflected in Algorithm 3, below. Consequently, the server can verify the proof of each client cfand put it to the malicious client list c* if the verification fails. The list c* is broadcast to all the clients.

[0077]

[0078] In another example, leveraging the same values given in the example provided for Figure 1, image (b), suppose fc = 2 and the random vectors are ao = (2, 1), at = (3,-1) and a2 = (-4, 2). The server precomputes h0= w^w^02= g10,^ = w^r2w212= g5,h2= w“22Wz22= g~4and broadcasts them to the clients. Client 2 checks the correctness of ho, hi, hi by randomly sampling (bo, bi, bi) = (5, 2,-3), computing and checking the correctness == wfw'2, which holds because both sides equal to g72. Client 2 then computes inner products v0= (a0,u2> = 11, = (a^) = 14, v2= (a2, u2) = -18 and commits = g~S8. Suppose that the additional independent group element is q = g~2. Client 2 uses random values (si, si) = (-4, 6) to commit oj = gl’LqS1= g22, o2= gV2qS2= g12, uses random values (sj.sz) = (8,3) to commit o( = gV2qs2' = g1S0,o2= g”2q'’2= g'3ia. After that, it generates a proof p that the same value (i.e., n) is used in the computation of zi and eo, ei, ei and that the same values (i.e., (vi, vi)) are used in the computation of e, o, a proof r that the secrets in o' are the squares of the secrets in o, a proof of bound a for vi, m based on oi, 02, and a proof of bound g for + v2based on o( • o2' = g5ia.

[0079] The server checks the correctness of eo, ei, ei by randomly sampling (a0,a1,a2) = (7,2, 4) CO m puting checking the correctness of e^e^e"2== y2py2%, which holds because both sides equal to g1137. The server then checks the proofs p, g. After successfully checking the proofs, the server is sure that Client 2 has committed to a model update U2 that passes the probabilistic L2-norm bound check in Algorithm 1.

[0080] After performing the proofs, in the secure aggregation round (Figure 1, image (d)), each client aggregates the secret shares from clients Cj(j g c) (i.e., aggregates the secret share generated by the client itself and any received secret shares from honest clients) and sends the result to the server. The server reconstructs the sum of secret shares and securely aggregates the updates u,( / g e*) based on the Pedersen commitments. This can then be used to update the FL model. Specifically, let c\c- be the set of honest clients. In this round, each client c e & selects the corresponding secret shares from the honest clients Cje aggregates the shares n' rji, and sends n' to the server. The server uses SS. Verify ,n,m + l,g)) to verify the integrity of each n', obtains the list of clients Cvaiid 3 that pass the integrity check, and computes r' <— SS.Recover({(i, n') ; i e Cvaiid}). According to the homomorphic property of is the summation of the honest clients' secrets. The summation will be used for calculating the aggregation of honest clients' model updates u = u,

[0081] Specifically, the server can multiply the commitments from honest clients

[0082] C / e C«and obtain: Without loss of generality, the Fh(I e [d]) dimension is considered to derive the calculation as follows. where m is the aggregation of the / lhlelements in honest clients' updates, w(is the common group element used for the commitment in Equation (1), and r is the summation of honest clients' secrets. Note that the derivation of Equation (6) is due to clients using the same group elements g and wi. Since the server has already calculated r = r' , it can thus compute gUlfor ( e [d] and solve ^according to Equation (7).

[0083] The embodiments described above employ the L2-norm bound check. The same methodology can be easily extended to support a wide range of defense methods. For instance, it can support the sphere defense, cosine similarity defense, and Zeno++ defense, which are designed based on variants of £2-norm bound check. Moreover, it can be extended to L«>-norm bound check, i.e., | ||„ Q , | |2| |d|), the vector's coordinate is less than a threshold.

[0084] For sphere defense, the server broadcasts a public vector v and a bound B, and then checks whether the model update u satisfies II U - V ||2< B. The protocol can be changed in which the ithclient commits to Ui-v instead of u<. The server then recovers SiecH(uf-v) and computes the set of honest clients.

[0085] For cosine similarity defense, the server broadcasts v, B and a public hyperparameter a, and then checks if the model update u satisfies both || u ||2< B and (u,v> > a || u ||2|| v ||2. A predicate can be added to the protocol that checks || u ||2< allvllj based on

[0086] Algorithm 1.

[0087] Forthe Zeno++ defense p,r, e are public hyperparameters, it can be converted into sphere defense b < || v ||2for the check. For Lco-norm bound check, the present approach can be adapted to use the idea of approximate proofs of L<» bound. To verify that ll u ||„< B, the client first commits u with the hybrid commitment scheme and commits an additional random vector z. The server then randomly samples ai,...,as from the discrete distribution P(-1) = P(1) = 1 / 4, P(0) = 1 / 2 , and broadcasts these vectors to the client. Next, the client proves to the verifier that Ka^u) + zj < B / y for every i e [1, fc]. The gap parameter y can be computed from fc, d and the security parameter using the technique in. If passed, the verifier can guarantee that is bounded with overwhelming probability.

[0088] The above techniques can still be used to generate and verify the proofs of (a;,u) with high efficiency.

[0089] Some embodiments have been modified to extend the method 100 to cover additional attacks. For example, the server or clients may cheat in other FL phases if they are malicious. For example, the server may send arbitrary aggregated model parameters to the clients for training, or a client may change its datasets in different iterations to initiate backdoor attacks. For the former case, the method 100 can be extended to further let the server broadcast the information received from the clients and let all the clients run the same proof verification and aggregation as the server. For the latter case, validating the well-formedness of model updates can mitigate the impact of such malicious behaviours. Each client may also commit its dataset before FL training and require it to generate a proof for each computation during training, so that the server can verify that the model update is computed correctly.

[0090] Figure 3 schematically represents a system 300 for performing the method 100. The system comprises a server 301, memory 302 and at least one processor 304. The server 301, memory 302 and processor 304 may be housed in the same unit, or may be separate. The system 300 also includes a plurality of clients 306 that interact with the server 301 over a network 308. The memory 302 and . / or processor or processors 304 may be distributed across the server 301 and client devices 306.

[0091] The memory 302 stores instructions in the form of program code 310, that is executed by the processor or processors to implement the method 100. In particular, on execution of the instructions 310, the server 301 transmits hyper-parameters for the FL model (stored in FL model module 309) from the server to all clients 306. The clients 306 generate the model updates, commitments and secret shares. The commitments are transmitted from the clients 306, over the network 308 to the server 301. The secret shares are transmitted between clients 306 - this may occur directly, or via the server 301.

[0092] Each client 306 receives a secret share from another client and verifies the received secret share using a zero-knowledge proof. The sending client is marked as malicious of the verification fails.

[0093] The server 301 then performs a probabilistic integrity check on the commitments and filters out commitments from any client marked as malicious.

[0094] The clients 306 then send to the server 301 an aggregate of the secret share generated by the respective client 306 and any received secret shares from honest clients 306, and the server 301 reconstructs a sum of the secret shares from honest clients 306 and aggregates the corresponding updates from the honest clients to update the FL model.

[0095] It will be appreciated that many further modifications and permutations of various aspects of the described embodiments are possible. Accordingly, the described aspects are intended to embrace all such alterations, modifications, and variations that fall within the spirit and scope of the appended claims.

[0096] Throughout this disclosure, unless the context requires otherwise, the word "comprise", and variations such as "comprises" and "comprising", will be understood to imply the inclusion of a stated integer or step or group of integers or steps, but not the exclusion of any other integer or step or group of integers or steps.

[0097] The reference to any prior art in this disclosure is not, and should not be taken as, an acknowledgement or any form of suggestion that the prior art forms part of the common general knowledge.

Claims

CLAIMS1. A method for updating a federated learning (FL) model, using a server and a plurality of clients, comprising, for each of one or more iterations: transmitting hyper-parameters for the FL model from the server to all clients; each client: generating a respective model update comprising updates to the hyper-parameters, based on private information of the respective client, and generating a respective commitment and secret share corresponding to the model update; transmitting the commitment to the server; and sharing the secret share with one or more other said clients; each client that receives a secret share from another said client verifying the received secret share using a zero-knowledge proof, and marking the another said client as malicious if the secret share is invalid; the server performing a probabilistic integrity check on the commitments and filtering out commitments from any client marked as malicious, any client not marked as malicious being an honest client; each client sending to the server an aggregate of the secret share generated by the respective client and any received secret shares from honest clients; and the server reconstructing a sum of the secret shares from honest clients, aggregating the corresponding updates from the honest clients to update the FL model.

2. The method of claim 1, wherein the commitments are generated, and the updates are aggregated using an additively homomorphic encryption scheme.

3. The method of claim 2, wherein the additively homomorphic encryption scheme uses Pedersen Commitment.

4. The method of any one of claims 1 to 3, wherein the secret shares are generated and verified according to an additively homomorphic sharing scheme.

5. The method of claim 4, wherein the additively homomorphic sharing scheme is Shamir's Secret Sharing Scheme.

6. The method of any one of claims 1 to 5, wherein verifying each said received secret share comprises using a Z-protocol for proof of square and proof of relation.

7. The method of any one of claims 1 to 6, wherein sharing the secret share with one or more other said clients comprises: each client encrypting its respective secret share using a public encryption key of a different said client, generating a check string corresponding to the encrypted secret share, and forwarding the encrypted secret share and check string to the server; and forwarding the encrypted secret share from the server to the different client; and forwarding the check string to all clients.

8. The method of any one of claims 1 to 7, wherein the server maintains a list of malicious clients for each iteration, the method further comprising: transmitting a maximum number m of malicious clients from the server to each client; each client marking another said client as malicious by adding the said client to a respective set of malicious clients and transmitting the set to the server; and if a number of malicious clients in the respective set is at most m, the malicious clients from the respective set are added to the list; and if the number of malicious clients in the respective set exceeds m, the client that sent the set is added to the list of malicious clients.

9. The method according to claim 8, wherein, if a said client is marked as malicious by at most m other said clients, the server verifies each secret share that the client sent to the other clients and: if any said secret share is found invalid, the client is added to the list of malicious clients; and for each said secret share found to be valid the corresponding other client is added to the list of malicious clients.

10. The method of any one of claims 1 to 6, wherein performing the probabilistic integrity check comprises: broadcasting a random value to all clients; computing a seed hash function at the server and each client, using the random value and a public encryption key for each client; and generating a set of random samples using the seed hash function; each client generating a commitment based on the respective update and set of random samples, the commitment being a function of independent group elements; merging the independent group elements and transmitting the merged group elements to each client; verifying, at the respective client, that the merged independent group elements are correct; and proving that a random variable following a Chi-square distribution xl with k degrees of freedom, is below a predetermined bound.

11. The method of claim 4 or 5, wherein reconstructing the sum of the secret shares from honest clients comprises aggregating, at each client, the secret shares received from honest clients, and wherein aggregating the corresponding updates from the honest clients to update the FL model comprises computing each honest client's secret share using a homomorphic property of the homomorphic sharing scheme.

12. A computer system for updating a federated learning (FL) model, comprising: memory; at least one processor; a server; and a plurality of clients, the memory storing instructions that, when executed by the one or more processors, cause the system to: transmit hyper-parameters for the FL model from the server to all clients; each client: generating a respective model update comprising updates to the hyper-parameters, based on private information of therespective client, and generating a respective commitment and secret share corresponding to the model update; transmitting the commitment to the server; and sharing the secret share with one or more other said clients; each client that receives a secret share from another said client verifying the received secret share using a zero-knowledge proof, and marking the another said client as malicious if the secret share is invalid; perform, at the server, a probabilistic integrity check on the commitments and filtering out commitments from any client marked as malicious, any client not marked as malicious being an honest client; each client sending to the server an aggregate of the secret share generated by the respective client and any received secret shares from honest clients; and reconstructing, at the server, a sum of the secret shares from honest clients, aggregating the corresponding updates from the honest clients to update the FL model.

13. The system of claim 12, wherein the commitments are generated, and the updates are aggregated using an additively homomorphic encryption scheme.

14. The system of claim 13, wherein the additively homomorphic encryption scheme uses Pedersen Commitment.

15. The system of any one of claims 12 to 14, wherein the secret shares are generated and verified according to an additively homomorphic sharing scheme.

16. The system of claim 15, wherein the additively homomorphic sharing scheme is Shamir's Secret Sharing Scheme.

17. The system of any one of claims 12 to 16, wherein sharing the secret share with one or more other said clients comprises: each client encrypting its respective secret share using a public encryption key of a different said client, generating a check string corresponding to theencrypted secret share, and forwarding the encrypted secret share and check string to the server; and forwarding the encrypted secret share from the server to the different client; and forwarding the check string to all clients.

18. The system of any one of claims 12 to 17, wherein the server maintains a list of malicious clients for each iteration, the method further comprising : transmitting a maximum number m of malicious clients from the server to each client; each client marking another said client as malicious by adding the said client to a respective set of malicious clients and transmitting the set to the server; and if a number of malicious clients in the respective set is at most m, the malicious clients from the respective set are added to the list; and if the number of malicious clients in the respective set exceeds m, the client that sent the set is added to the list of malicious clients.

19. The system of any one of claims 12 to 16, wherein performing the probabilistic integrity check comprises: broadcasting a random value to all clients; computing a seed hash function at the server and each client, using the random value and a public encryption key for each client; and generating a set of random samples using the seed hash function; each client generating a commitment based on the respective update and set of random samples, the commitment being a function of independent group elements; merging the independent group elements and transmitting the merged group elements to each client; verifying, at the respective client, that the merged independent group elements are correct; and proving that a random variable following a Chi-square distribution Xk with k degrees of freedom, is below a predetermined bound.

20. The system of claim 15 or 16, wherein reconstructing the sum of the secret shares from honest clients comprises aggregating, at each client, the secretshares received from honest clients, and wherein aggregating the corresponding updates from the honest clients to update the FL model comprises computing each honest client's secret share using a homomorphic property of the homomorphic sharing scheme.

Images