A poison-resistant federated learning method

Abstract

The present invention discloses a method for federated learning that resists poisoning, including: generating a random shared key using a non-interactive key; generating a shared random number using a hash function and a random shared key; the shared random number ensures the validity of the shared input data; the first, second, and third servers verify the consistency of the correlation data; exclude servers with inconsistent correlation data; filter abnormal gradients through correlation data; and aggregate all legal gradients to complete model updates. The present invention uses a three-server model to build a client-friendly framework to ensure output delivery. Use consistency checks to detect abnormal behavior. Use consistency checks to implement input and output verification detection to prevent malicious servers from colluding with malicious clients to aggregate poisoned gradients.

Description

Technical Field

[0001] The present invention relates to the technical field of machine learning, and in particular to a federated learning method that is resistant to poisoning. Background Art

[0002] With the rapid popularization of smart wearable devices, federated learning (FL) has shown great value in privacy-sensitive data distribution applications, especially in the field of medical diagnosis. Federated learning technology allows all participants to jointly train a global model without sharing original data, thereby effectively protecting user privacy. However, the federated learning architecture based on a central server is vulnerable to poisoning attacks because the server has the dominant position in the model aggregation process, and attackers can use this process to inject backdoors into the global model. In order to reduce the security risks brought by centralized servers, some recent solutions have introduced a dual-server mode and provided a more efficient distributed trust federated learning architecture through abnormal gradient filtering. For example, it grows linearly with the number of servers and gradients.

[0003] Existing federated learning (FL) solutions lack robustness and are vulnerable to in-protocol denial-of-service (DoS) attacks. For example, a "lazy" server may refuse to accept gradients from certain clients to reduce its computational burden. In more serious cases, a malicious server may terminate the protocol after obtaining the final model, resulting in honest parties (such as patients or medical institutions) being unable to obtain the results. Few studies have focused on the robustness of federated learning systems. Although the use of a fault-tolerant multi-party computation (MPC) framework can defend against such attacks, the large-scale interpolation and commitment poses a huge computational burden for resource-constrained devices such as wearable watches.

[0004] The two-server federated learning framework is still vulnerable to poisoning attacks, especially when collusion between the server and the client is possible. For example, in some applications of federated learning models, the client must compute a non-interactive proof of secret sharing to ensure the correctness of the gradient. However, a malicious server may collude with the client to bypass the verification and inject malicious gradients into the global model. Summary of the invention

[0005] The embodiment of the present invention provides a poison-resistant federated learning method to solve the problem in the prior art that, when collusion may occur between the server and the client, a malicious server may collude with the client to bypass verification and inject malicious gradients into the global model.

[0006] On the one hand, an embodiment of the present invention provides an anti-poisoning federated learning method, including:

[0007] Generate a random shared key through a non-interactive key;

[0008] Generate a shared random number using a hash function and the random shared key;

[0009] Ensuring the consistency of shared input data by using the shared random number;

[0010] The first server generates correlation data and sends it to the second server and the third server;

[0011] The first server, the second server and the third server verify the consistency of the correlation data;

[0012] Excluding servers having inconsistent correlation data among the first server, the second server, and the third server;

[0013] The first server, the second server and the third server filter abnormal gradients through the correlation data;

[0014] The first server, the second server and the third server aggregate all legal gradients to complete the model update.

[0015] In a possible implementation manner, before the generating a random shared key by using a non-interactive key, the process further includes:

[0016] Generate a public key and private key pair for each server through a public key generator;

[0017] Generate common parameters between all the servers through a public key generator.

[0018] In a possible implementation manner, before ensuring the consistency of shared input data by using the shared random number, the method further includes:

[0019] Each of the shared random numbers is jointly held by the two servers, and the shared random numbers are checked for consistency through hash values ​​to ensure that the shared random numbers are correct and valid.

[0020] In a possible implementation, ensuring the consistency of shared input data by using the shared random number includes:

[0021] The client masks the local gradient using the shared random number provided by the server to obtain the masked gradient;

[0022] The mask gradient of each client is sent as input to the server for exchange and consistency verification as valid shared input data.

[0023] In a possible implementation, the first server generating correlation data and sending the data to the second server and the third server includes:

[0024] The first server generates OT and square correlation data;

[0025] The OT and square correlation data are distributed to the second server and the third server through the LocalOT algorithm.

[0026] In a possible implementation, the first server, the second server, and the third server filtering abnormal gradients through the correlation data include:

[0027] The first server, the second server and the third server verify the constraint of the mask gradient through the correlation data;

[0028] The abnormal gradients that do not satisfy the constraints are filtered.

[0029] In a possible implementation, the first server, the second server, and the third server aggregate all legal gradients to complete the model update, including:

[0030] Each of the servers aggregates all the legal gradients that pass the filtering;

[0031] Detecting the aggregation result to ensure that the aggregation results of all the servers are consistent;

[0032] The server whose aggregation results are inconsistent is eliminated to ensure the accuracy of the model update.

[0033] The anti-poisoning federated learning method of the present invention has the following advantages:

[0034] (1) A client-friendly framework is built using a three-server model to guarantee output delivery. Consistency checks are used to detect abnormal behavior, eliminating the expensive overhead of zero-knowledge proofs.

[0035] (2) The pseudo-random function combined with key homomorphism reduces the client's computational overhead and provides an efficient result recovery method when no user is disconnected.

[0036] (3) Use consistency checks to implement input and output verification detection to prevent malicious servers from colluding with malicious clients to aggregate poisoning gradients. BRIEF DESCRIPTION OF THE DRAWINGS

[0037] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0038] Figure 1A schematic diagram of the operation of an anti-poisoning federated learning method provided in an embodiment of the present invention. DETAILED DESCRIPTION

[0039] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0040] Figure 1 A schematic diagram of the operation of a poison-resistant federated learning method provided by an embodiment of the present invention; an embodiment of the present invention provides a poison-resistant federated learning method, including:

[0041] Generate a random shared key through a non-interactive key;

[0042] Generate a shared random number using a hash function and the random shared key;

[0043] Ensuring the consistency of shared input data by using the shared random number;

[0044] The first server generates correlation data and sends it to the second server and the third server;

[0045] The first server, the second server and the third server verify the consistency of the correlation data;

[0046] Excluding servers having inconsistent correlation data among the first server, the second server, and the third server;

[0047] The first server, the second server and the third server filter abnormal gradients through the correlation data;

[0048] The first server, the second server and the third server aggregate all legal gradients to complete the model update.

[0049] In a possible embodiment, before the generating a random shared key by using a non-interactive key, the method further includes:

[0050] Generate a public key and private key pair for each server through a public key generator;

[0051] Generate public parameters between all the servers through a public key generator;

[0052] Before ensuring the consistency of shared input data by the shared random number, the following step is also included:

[0053] Each of the shared random numbers is held by the two servers together, and the shared random number is checked for consistency through a hash value to ensure that the shared random number is correct and valid;

[0054] Ensuring the consistency of shared input data by sharing random numbers includes:

[0055] The client masks the local gradient using the shared random number provided by the server to obtain the masked gradient;

[0056] Sending the mask gradient of each client as input to the server for exchange and consistency verification as valid shared input data;

[0057] The first server generates correlation data and sends it to the second server and the third server, comprising:

[0058] The first server generates OT and square correlation data;

[0059] The OT and square correlation data are distributed to the second server and the third server through the LocalOT algorithm;

[0060] The first server, the second server, and the third server filter abnormal gradients through the correlation data including:

[0061] The first server, the second server and the third server verify the constraint of the mask gradient through the correlation data;

[0062] filtering the abnormal gradients that do not satisfy the constraints;

[0063] The first server, the second server, and the third server aggregate all legal gradients to complete the model update, including:

[0064] Each of the servers aggregates all the legal gradients that pass the filtering;

[0065] Detecting the aggregation result to ensure that the aggregation results of all the servers are consistent;

[0066] The server whose aggregation results are inconsistent is eliminated to ensure the accuracy of the model update.

[0067] Exemplarily, the method of this embodiment mainly includes six stages: system initialization, shared input generation, random generation of correlation, correlation verification, L2 calculation, aggregation and update.

[0068] System initialization: During the system initialization phase, the public key generator (PKG) generates a public key and private key pair for each server and initializes the state of the global model. At the same time, PKG generates public parameters between servers to ensure the security of communication between servers. Each pair of servers generates a consistent random key through the non-interactive Diffie-Hellman key exchange protocol, and uses a hash function to generate a series of associated shared random numbers for subsequent security operations. Each random number share is held by two servers and is checked for consistency through hash values ​​to ensure the correctness of the random number. If an inconsistency is detected, the PlayerElim mechanism is initiated to identify and exclude possible malicious behavior.

[0069] Shared input generation: During the shared input generation phase, the client uses the shared random number provided by the server to mask its local gradient. The masked gradient generated by each client is sent to the server as input. After receiving the masked data, the server exchanges and performs consistency verification to ensure that the data remains intact during transmission. Finally, the server checks the bit length of the received gradient to ensure that it meets the L ∞ The safety constraint of the norm (Chebyshev distance) is set as valid shared input data for subsequent calculations.

[0070] Random correlation generation: In this stage, the first server is responsible for generating the required correlation data, including OT (Oblivious Transfer) and square correlation data. The generated correlation data is distributed to other servers through the LocalOT algorithm to ensure that the subsequent L 2 norm calculations. Each server collaborates to verify the consistency of the correlation data to ensure the randomness and correctness of the data, thus providing L 2-norm defense mechanism lays the foundation.

[0071] Correlation Verification: Since the first server is not trusted, the other servers (second and third servers) need to verify the correlation data generated by the first server. By exposing part of the correlation to check the correctness of the rest, the second and third servers can ensure the legitimacy of the correlation data. In addition, each server performs a hash check on the generated calculation results to ensure data consistency. If any inconsistency is detected, the PlayerElim mechanism will be activated to identify and exclude non-compliant servers to ensure system security and data integrity.

[0072] L 2-norm calculation: L 2-norm calculation phase, each server converts Boolean shares into arithmetic shares L2 norm calculation. The server uses the previously generated correlation data to verify the L 2 norm constraint, thereby filtering out abnormal gradients. In this process, even if a server terminates the operation due to malicious behavior, other servers can still continue to complete the calculation, ensuring the robustness of the system and reliable output.

[0073] Aggregation and Update: In the aggregation and update phase, the server L Aggregate the legal gradients verified by the 2-norm and check whether the aggregation results meet L 2-norm constraint. If the aggregation results of all servers are consistent, the system completes the update of the global model and provides it to the client to support the next round of training; if inconsistency is detected, the PlayerElim mechanism is activated to identify malicious servers and eliminate non-compliant data or servers, thereby ensuring the accuracy and security of the model update.

[0074] The PlayerElim algorithm of this embodiment refers to using mutual accusations between servers. Finally, since the honest servers occupy the majority, the honest servers can be responsible for the calculation. Specifically, the PlayerElim algorithm is described as follows:

[0075] 1. : The server accuses it of receiving News With from News Inconsistent. and There is a computational conflict if and If there is no next response, the next calculation will be kicked out. and .

[0076] 2. :if Received from other servers (for example: ) ,However, The accusation message Not really Sent. At this time, Will blame the server instead ,Right now and There is a calculation conflict, the next calculation will be kicked out and ,in and It means that when a server receives messages from different servers, the messages it receives are inconsistent, and it is necessary to exclude one or two servers with conflicts from subsequent calculations. and Refers to the i-th and j-th servers respectively. The value range of i and j is (1, 2, 3). The corresponding messages and Message Refers to the server and Received message.

[0077] In a possible embodiment, the solution of this embodiment is Client and a security parameter To instantiate the protocol. represents the dimension of the gradient. To defend against poisoning attacks, Set as The upper bound of the norm and Set as The upper bound of the norm. RoseFL involves three servers , and , where the server Responsible for generating correlations and providing and The transcription between and The validity of correlations and gradients is jointly verified. After each calculation, the servers will check the consistency of the results they receive to detect possible misbehavior. For simplicity, it is assumed that each client is assigned a unique logical identity, denoted by Specifically, the five stages are described in detail as follows:

[0078] System initialization: The servers generate a random shared key through a non-interactive Diffie-Hellman key exchange, and use a hash function to generate multiple associated random shared numbers for each client's secret sharing. These shared numbers are expressed as , Indicates the client ID. Represents a server pair. Each server can generate a set of random numbers to share , through the hash function Generate a shared number, where is a randomly generated seed, Is a global counter. Each server performs consistency check on the shared random number, and each pair of servers exchanges the calculated hash value. To verify the consistency of the shared number. If the consistency verification fails, the server Call The protocol identifies and excludes servers with malicious behavior. This initialization process ensures the correctness and security of shared data and only needs to be called once.

[0079] Shared input generation: During the shared input generation phase, the client uses the random shared number provided by the server to mask the local gradient. , each server Providing shared data to clients and , and the hash value After receiving the shared numbers from multiple servers, the client selects a consistent shared number pair to ensure the correctness of the data. Subsequently, the client uses the consistent shared number to pair the local gradient Masking is performed to generate the blinded gradient expression as:

[0080]

[0081] The client will The servers receive the blinded gradients and exchange data with each other to verify the consistency of the received information. After confirming the consistency, the server checks the bit length of the gradient to ensure that the gradient meets the norm and mark the gradients that pass the verification as valid shared inputs.

[0082] Correlation is randomly generated: In this phase, the server Responsible for generating the required correlation data, including OT (Oblivious Transfer) and square correlation data. The core algorithm of this process is called LocalOT. The input of the LocalOT algorithm is a bit string and an offset , the output is two sets and , the two satisfy the relationship: , is the preset offset. In this process, for each client Gradient Every one of us, server First, from the finite field Generate two random offsets in and , and from Randomly select two random vectors from and ,in: Next, the server Generate OT correlation by calling LocalOT algorithm:

[0083]

[0084]

[0085] Then, the server Need to generate squared correlation for secure bitwise multiplication. The server takes the set Random selection Random values , and calculate their arithmetic share and For each random value , the square value is calculated by the following formula:

[0086]

[0087] Finally, the server The tuple Send to server .

[0088] Correlation Verification: In secure multi-party computation, the server The generated correlations may be unreliable, so a verification mechanism is needed to ensure that these correlations are correct. During the correlation verification phase, the server and Requires verification Whether the generated correlation is correct, the core idea of ​​the algorithm design is to verify the correctness of the remaining undisclosed part by disclosing a part of the correlation. Expose the generated partial dependencies to and ,Then The resulting hash value is calculated each time and sent to other servers. and It will be verified by checking the consistency of these hash values Whether all dependencies are generated correctly.

[0089] To verify these dependencies, the server Will choose some and The elements of right For these public elements, the server and Will calculate and verify whether:

[0090]

[0091] If all the public parts satisfy this equation, then it can be inferred with a high probability that the remaining undisclosed parts are also correct. On the contrary, if it does not satisfy this equation, then it means The behavior is abnormal.

[0092] Calculation: All servers perform calculations by converting Boolean shares into arithmetic shares, ensuring that they can perform correct calculation operations using verified correlations. This conversion process ensures that even if one server may be malicious, other servers can still continue to calculate and ensure correctness. Assume that the server Holding Boolean Shares and , the server performs bitwise multiplication to convert these Boolean shares into arithmetic shares. In addition, the server and Also holds Boolean shares , they can assist in the calculation process and ensure the accuracy of the conversion. To verify consistency, the server Transcription will also be provided Give , used to check the correlation generated during the calculation process. For each client arrive , the server processes each dimension and each bit separately. arrive , the server will perform a Boolean operation on the shares of the current dimension. Every one of The server first checks the current Calculate the hash value: , this step ensures that each bit of the share is processed independently; then, the server calculates the second hash value , and compare it with the offset Addition: , and then calculate the intermediate variable , this value is used for further processing.

[0093] server Calculate and send To the server , for subsequent verification: .at the same time, Will receive News If the received message If the server is consistent, it will perform the share conversion operation: First, the server calculates the hash value again , but this time based on correlation : ; The server uses XOR operation , and then update as follows: ; Calculate the updated correlation value and , the formula is as follows:

[0094]

[0095] If the message between the servers If the value is inconsistent, it indicates that there may be malicious behavior. At this time, the PlayerElim algorithm will be called to identify and eliminate the wrong behavior. and , then update the relevance share :

[0096]

[0097] Make sure the final arithmetic share is updated correctly.

[0098] Aggregate and Update: The server will check The core idea of ​​this phase is to ensure that the gradients on each server are within the predefined Within the upper limit, only legal gradients will be used to update the global model. First calculate: .in, is predefined The server then extracts the sign bit from the calculation result. If the sign bit is 1, it means that the gradient Less than , indicating that the gradient is legal; otherwise, the server will reject the gradient. Next, all servers can use these legal gradients for robust aggregation. Aggregation results By the server Computed and held by the server The consistency of the final aggregation result is checked by the following formula:

[0099]

[0100] If this equation holds true, the aggregation results are consistent and correct, and the server Accept and update the global model The updated global model will be distributed to all clients for the next iteration. Otherwise, the server The PlayerElim algorithm will be called to exclude possible malicious servers and ensure that the final calculation results are provided by honest servers.

[0101] Although the preferred embodiments of the present invention have been described, those skilled in the art may make additional changes and modifications to these embodiments once they have learned the basic creative concept. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments and all changes and modifications that fall within the scope of the present invention.

[0102] Obviously, those skilled in the art can make various changes and modifications to the present invention without departing from the spirit and scope of the present invention. Thus, if these modifications and variations of the present invention fall within the scope of the claims of the present invention and their equivalents, the present invention is also intended to include these modifications and variations.

Claims

1. A poison-resistant federated learning method, characterized in that: include: Generate a random shared key through a non-interactive key; Generate a shared random number using a hash function and the random shared key; Ensuring the consistency of shared input data by using the shared random number; The first server generates correlation data and sends it to the second server and the third server; The first server, the second server and the third server verify the consistency of the correlation data; Excluding servers having inconsistent correlation data among the first server, the second server, and the third server; The first server, the second server and the third server filter abnormal gradients through the correlation data; The first server, the second server and the third server aggregate all legal gradients to complete the model update; Random correlation generation: In this stage, the first server is responsible for generating the required correlation data, including OT and square correlation data. The generated correlation data is distributed to other servers through the LocalOT algorithm to ensure that the subsequent L 2 norm calculation, each server collaborates to verify the consistency of the correlation data to ensure the randomness and correctness of the data, thus L 2-norm defense mechanism lays the foundation.

2. The anti-poisoning federated learning method according to claim 1, characterized in that: Before the generating of the random shared key by the non-interactive key, the following step is also included: Generate a public key and private key pair for each server through a public key generator; Generate common parameters between all the servers through a public key generator.

3. The anti-poisoning federated learning method according to claim 2, characterized in that: Before ensuring the consistency of shared input data by the shared random number, the following step is also included: Each of the shared random numbers is jointly held by the two servers, and the shared random numbers are checked for consistency through hash values ​​to ensure that the shared random numbers are correct and valid.

4. The anti-poisoning federated learning method according to claim 3, characterized in that: Ensuring the consistency of shared input data by sharing random numbers includes: The client masks the local gradient using the shared random number provided by the server to obtain the masked gradient; The mask gradient of each client is sent as input to the server for exchange and consistency verification as valid shared input data.

5. The anti-poisoning federated learning method according to claim 4, characterized in that: The first server generates correlation data and sends it to the second server and the third server, comprising: The first server generates OT and square correlation data; The OT and square correlation data are distributed to the second server and the third server through the LocalOT algorithm.

6. The anti-poisoning federated learning method according to claim 5, characterized in that: The first server, the second server, and the third server filter abnormal gradients through the correlation data including: The first server, the second server and the third server verify the constraint of the mask gradient through the correlation data; The abnormal gradients that do not satisfy the constraints are filtered.

7. The anti-poisoning federated learning method according to claim 6, characterized in that: The first server, the second server, and the third server aggregate all legal gradients to complete the model update, including: Each of the servers aggregates all the legal gradients that pass the filtering; Detecting the aggregation result to ensure that the aggregation results of all the servers are consistent; The server whose aggregation results are inconsistent is eliminated to ensure the accuracy of the model update.

Images