Multi-participant vertical federated learning method based on data alignment and privacy protection

Abstract

The present application relates to a kind of multi-participant longitudinal federated learning method based on data alignment and privacy protection, belong to data security field.The present application meets the requirements of data privacy protection and data cooperation by fusing the security calculation of multi-party data, while supporting users to solve data leakage and privacy violation problems;The present application method combines zero-knowledge proof and homomorphic encryption technology to construct a secure multi-party data alignment mechanism, protects data privacy through efficient encryption means, and uses multi-party private set intersection calculation to realize the safe identification of common user data, improves the security and efficiency of data cooperation;The present application's violation handling and reward and punishment mechanism, under the supervision of third-party inspection agency, ensures that the participant complies with the agreement in the process of data alignment and model training, prevents data abuse, and enhances the reliability of the agreement and the compliance of the participant.

Description

TECHNICAL FIELD

[0001] The present application belongs to the technical field of data security, and relates to a multi-participant vertical federated learning method based on data alignment and privacy protection. BACKGROUND

[0002] With the continuous strengthening of data privacy protection and data security regulations (such as GDPR and CCPA), data holders are facing higher privacy protection requirements. In this context, traditional data sharing and centralized processing methods are challenged and cannot be directly applied to data collaboration in privacy-sensitive fields such as finance, healthcare, and telecommunications. Federated learning (FL) is a distributed machine learning framework that allows data holders to jointly train models without sharing raw data, thereby achieving privacy protection in data collaboration. In federated learning, vertical federated learning (VFL) is particularly suitable for scenarios where different industry institutions have different dimensions of feature data for the same user group. Through VFL, participants from different industries can build collaborative models based on different data features of the same user to improve business accuracy, such as user credit scoring or personalized recommendations. VFL generally consists of two steps: first, sample alignment; second, model encryption training on aligned samples. However, a key problem faced by VFL is how to align data samples while ensuring privacy to identify users owned by participants (i.e. intersection users) and achieve data collaboration.

[0003] For example, Liu et al. in “Asymmetrical Vertical Federated Learning”

in arXiv preprint arXiv:2004.07427, 2020.

in Wireless Communications and Mobile Computing, 2021, 2021(1): 6692061.

[0004] Existing technologies usually use private set intersection (PSI) technology to realize data sample alignment, which ensures that each party can only obtain the set information of the intersection users through encryption without revealing the information of non-intersection users. PSI technology performs well in two-party scenarios, but in multi-party scenarios, traditional two-party PSI protocols have many shortcomings. In vertical federated learning, if participants fake false ID sets for privacy intersection alignment or use incomplete user sets for intersection operations, it may pose a security threat. The following are the shortcomings of existing solutions:

[0005] (1) Scalability: Existing VFLs use PSI protocols that mostly support two-party intersection alignment computation and cannot be directly extended to multi-party scenarios. In multi-party data collaboration, if the pairwise intersection approach is used, the computational complexity will increase exponentially with the number of participants. At the same time, the integration of pairwise intersection results also faces many challenges, and is prone to data inconsistency and error accumulation, which seriously affects the efficiency and accuracy of multi-party data collaboration, making it difficult to meet the demand for large-scale multi-party data alignment in practical applications.

[0006] (2) Privacy leakage risk: Falsifying fake ID sets can lead to attribute inference attacks, and attackers may infer sensitive information about the training data by analyzing the model's output or gradient. This attack is particularly concerning in vertical federated learning, as the user's original data does not leave the local, but the output of the model can still leak privacy information. Training using incomplete intersection result data can result in incomplete data for model training, affecting the accuracy and generalization ability of the model. In addition, if a participant intentionally provides false data, it can contaminate the model and affect the prediction results of the model, thereby reducing the reliability and effectiveness of the model. Falsified or incomplete data can prevent the model from effectively learning, thereby affecting the performance of the model in practical applications. The model may not be able to accurately capture patterns and trends in the data, resulting in decreased prediction accuracy.

[0007] Therefore, there is a need for an improved multi-party private set intersection protocol that can achieve efficient intersection computation under multi-party participation while ensuring data privacy protection and compliance supervision to meet the requirements of vertical federated learning for data alignment and privacy protection. SUMMARY

[0008] Therefore, the purpose of the present application is to provide a multi-participant vertical federated learning method based on data alignment and privacy protection by combining private set intersection, zero-knowledge proof, homomorphic encryption, and third-party audit technology, to solve the privacy protection and compliance problems in multi-party data collaboration in the vertical federated learning environment, and to provide an efficient and secure data sharing solution. The present application introduces a third-party audit institution (TPA) to supervise and verify the key steps of intersection computation and federated learning training, ensuring that each party follows the protocol during data alignment and training, and avoiding the behavior of falsifying data or using data improperly. The TPA uses zero-knowledge proof and homomorphic encryption to verify the authenticity and integrity of the data, effectively preventing possible privacy leakage and unfair competition issues.

[0009] To achieve the above purpose, the present application provides the following technical solutions:

[0010] A multi-participant vertical federated learning method based on data alignment and privacy protection, comprising the following steps:

[0011] S1: protocol initialization phase: initialize the protocol, and a trusted authority TA registers and signs an ID;

[0012] S2: user ID verification phase: each participant uses zero-knowledge proof to prove the legitimacy of the user ID;

[0013] S3: multi-party private set intersection (MPSI) phase: a third-party auditing authority TPA performs intersection calculation using the verified user ID hash set to ensure that only the real user IDs of each party are included in the intersection set;

[0014] S4: encryption verification and homomorphic encryption check phase: the TPA performs encryption verification and dynamic homomorphic encryption check to ensure that each party only trains on the complete intersection user set S;

[0015] S5: violation handling and reward and punishment mechanism phase: when a violation by a participant is detected, the TPA handles it according to the predetermined reward and punishment mechanism.

[0016] Further, the protocol initialization in step S1 comprises:

[0017] The protocol includes P1,...,P t Each party, and the private data set held by each party is S1,S2,...,S t , each set contains n i elements, and the goal of the protocol is to obtain the intersection through secure calculation: Ensure that each party can only train on the intersection users; among the participants, P1 to P t-1 are called clients, P t is the server side, and the TPA serves as an auditing authority to supervise the entire process, and the TA is a trusted authority that registers and signs the ID;

[0018] The trusted authority TA registers and signs the ID, specifically comprising:

[0019] Each participant P i sends the ID set of its users to the TA, and the TA verifies each ID received, and for the ID that passes the verification, the TA uses an asymmetric encryption algorithm to sign the ID-related information using the TA's private key, issues a certificate Cert(ID) containing the signature and TA public key information for the participant P i , and sends it back to the corresponding participant P i for saving.

[0020] Furthermore, step S2 specifically includes the following steps:

[0021] S21: Generate User ID Hash: First, set the user's certificate Cert(ID) hash. i ) and the corresponding user ID set ID i Perform the binding; then, combine the binding result with the user ID set to perform user ID hash calculation for each participant P. i Set its user IDs Perform a hash transformation to obtain a hash set:

[0022]

[0023] Where h is a one-way hash function, ensuring that TPA cannot restore the original value of the user ID;

[0024] S22: Generate zero-knowledge proof: Participant P i Generate a zero-knowledge proof π for each hash value. i,j , so that:

[0025] π j =ZKP(h(ID) j ),AC)

[0026] Here, AC indicates that the ID meets the authenticity requirements.

[0027] A zero-knowledge proof process based on the Schnorr protocol is adopted: Assume that each user ID corresponds to a hash value h(ID). i,j There is a secret x j The signing key derived from the user ID satisfies the following relationship:

[0028]

[0029] Where g is a generator and p is a large prime number;

[0030] The prover wants to prove that he knows x j , making It is valid, but x is not directly disclosed. j Combined with certificate Cert(ID) i The relevant information in the document ensures that the entire verification process reflects the authenticity of the ID and the validity of the certificate;

[0031] S23: Participant P i Hash set H i The corresponding zero-knowledge proof {π} i,j The bound certificate and ID set are submitted together to the TPA;

[0032] S24: Verify the zero-knowledge proof: TPA receives each participant P i The submitted hash set H i , the corresponding zero-knowledge proof set {π i,j}, and the bound certificate and ID set, and performs the following verification steps:

[0033] First, get the trusted authority's public key from the certificate, verify the signature of the certificate Cert(ID i ) is valid, check if the certificate is within the valid period, and check if the ID information in the certificate is consistent with the submitted ID set; if the certificate verification fails, directly determine that the ID set submitted by the participant is invalid, and mark it as a violation; if the certificate verification is passed, verify the zero-knowledge proof, for each h(ID i,j ) ∈ H i , TPA uses the verification algorithm Verify to check if the corresponding proof π i,j is valid: Verify(h(ID i,j ), π i,j ) = True, if the verification is passed, record h(ID i,j ) as a legal user ID; otherwise, mark it as invalid;

[0034] S25: Record the legal user ID hash set: after verification, TPA records the legal user ID hash set of each participant.

[0035] Further, step S3 specifically includes the following steps:

[0036] S31: Input of MPSI and encrypted inverse bloom filter generation and sending to server side P t ;

[0037] S32: MPSI calculation: the server first calculates the hash value for each element in the user ID set, and finds the matching item in the client's encrypted inverse bloom filter; the server calculates the sum of the ciphertext and re-randomizes the processing; the server distributes the encrypted result to the selected client, and the client feeds back after decryption; the server aggregates the decryption result to form the intersection set, which is submitted to TPA for confirmation and used for federated training.

[0038] Further, the input of MPSI and the generation of encrypted inverse bloom filter in step S31 include the following steps:

[0039] S311: Input: each client P1-P t-1 holds a shared decryption key sk i , which belongs to an additive homomorphic threshold encryption scheme with zero decryption algorithm ShDec0; the public key pk is visible to all parties;

[0040] S312: Initialization: Server P t Randomly select a set of hash functions and send to the clients;

[0041] S313: Local encrypted inverse bloom filter generation: Each client performs the following steps to generate an encrypted inverse bloom filter, thus achieving privacy-preserving user ID encryption: computes the bloom filter BF i of its user ID set S i , obtains the inverse bloom filter IBF i of the bloom filter, encrypts each element in IBF i to obtain the encrypted inverse bloom filter and sends it to the server P t .

[0042] Further, in step S32, the server P t performs the following steps to calculate the intersection user set:

[0043] For each element y t in the user ID set S j held by the server, compute k hash values h d (y j ), and for each hash value h d (y j ), find the value in the inverse bloom filter IBF i of each client:

[0044]

[0045] Calculate the sum of ciphertexts and re-randomize:

[0046]

[0047] The server distributes the result to any of the t-1 clients and requests them to decrypt each e j ;

[0048] Compliance check: Each client P i computes its decrypted share sh i,j and feeds it back to the server, as follows:

[0049] (1) The client first randomizes e j , sends the randomized back to the server, and the server combines it into and sends it to each client;

[0050] (2) The server summarizes the decryption share (sh) reported by the client. i,j This ultimately forms the decryption share set sh 1,j ,...,sh t-1,j ;

[0051] TPA verifies the decryption process: TPA monitors the client's decryption feedback process to ensure that all feedback is sent through a secure channel and to prevent the server or client from interfering with the calculation results by manipulating the feedback data; TPA randomly checks the client's feedback decryption share to ensure that the decryption process is compliant;

[0052] (3) The server uses a combination algorithm for decryption, for each j∈{1,...,n t The server uses a combinatorial algorithm to calculate: Dec(e) j )←Comb(sh 1,j ,...,sh t-1,j If the decryption result is zero, i.e., Dec(e) j If ) = 0, then it means y j From the set of user IDs of all participants, the server will select y j Add to the intersection set S = {y j}∪S; otherwise, discard y j ;

[0053] The final intersection set of users is output as follows: Server P t Finally, the intersection set S is output and the result is submitted to TPA for final confirmation. After TPA verifies the intersection result, it sends the compliant intersection set to all parties.

[0054] Furthermore, step S4 specifically includes the following steps:

[0055] S41: Encrypted Verification Mechanism: Before each round of training begins, TPA requires all parties to submit a set of encrypted hashes S of user IDs used for training to verify the compliance of the training data; each party generates an encrypted hash set, and TPA verifies whether these sets are consistent with the known complete intersection set; if the verification passes, it indicates that the parties are training on the correct intersection users; if it fails, TPA will record the violation.

[0056] S42: Dynamic Homomorphic Encryption Check: TPA employs dynamic homomorphic encryption check technology to prevent participants from using non-overlapping user data in certain rounds; firstly, checkpoints are randomly generated: TPA generates checkpoints in random rounds during training, requiring each participant to resubmit encrypted training data sets. Then, homomorphic encryption verification: TPA uses homomorphic encryption at checkpoints for verification. Whether it is consistent with E(S) ensures that the training data in each round comes from the complete intersection;

[0057] S43: Training phase: After determining the common entities, the parties use the data of these common entities to collaboratively train a machine learning model.

[0058] Further, the training phase described in step S43 includes the following steps:

[0059] S431: The trusted coordinator creates a key pair and sends the public key to the client and the server;

[0060] S432: The client and the server encrypt and exchange intermediate results, which are used to help calculate the gradient and the loss value;

[0061] S433: The client and the server calculate the encrypted gradient and add additional masks respectively, the server calculates the encrypted loss, and the client and the server send the encrypted results to the trusted coordinator;

[0062] S434: The trusted coordinator decrypts the gradient and loss information and sends the results back to the client and the server; the client and the server remove the masks on the gradient information and update the model parameters according to the gradient information.

[0063] Further, step S5 specifically includes the following steps:

[0064] Violation detection: The TPA uses zero-knowledge proof and encryption verification technology in each key step to regularly check the compliance of each party;

[0065] Penalty measures: For the parties confirmed to violate the rules, the TPA will take the following measures:

[0066] (1) Model weight reduction: Reduce its contribution weight in the federated model;

[0067] (2) Economic penalties: impose economic penalties on the violating party;

[0068] (3) Cooperation restriction: suspend its participation qualification in federated learning in the case of serious violation;

[0069] Reward measures: For the compliant parties, the TPA issues a compliance certificate and gives appropriate rewards to encourage parties to follow the agreement.

[0070] The beneficial effects of the present application are that the present application realizes the authenticity verification and safe sharing of data under the premise of ensuring the privacy of the participating parties; at the same time, the signature of the trusted certification agency and the real-time supervision of the third-party auditing agency guarantee the fairness and compliance of the data alignment and federated training process, and effectively prevent the behavior of forging data, thereby improving the efficiency and reliability of cross-industry multi-party cooperation, enhancing user trust and meeting legal compliance requirements.

[0071] (1) This invention proposes a privacy intersection alignment method that can be directly extended to multi-party scenarios by improving the traditional two-party PSI protocol, effectively solving the problem of insufficient scalability of existing technologies in multi-party data collaboration. This method reduces the computational complexity that increases exponentially with the number of participants by introducing the intersection calculation of multi-party private sets, and ensures the consistency and accuracy of data, meeting the needs of large-scale multi-party data alignment in practical applications.

[0072] (2) This invention introduces strict privacy protection measures in the data alignment and federated training phases to ensure that all participants use real IDs for intersection alignment and use only complete intersection user data during training. Through user ID verification and encryption verification mechanisms, this invention effectively prevents attribute inference attacks and privacy leakage risks, while ensuring the integrity and authenticity of the data used for model training, improving the accuracy, generalization ability, and reliability of the model, thereby enhancing the security of data use and the performance of the model in vertical federated learning.

[0073] Other advantages, objectives, and features of the invention will be set forth in part in the description which follows, and in part will be apparent to those skilled in the art from the following examination, or may be learned from practice of the invention. The objectives and other advantages of the invention can be realized and obtained through the following description. Attached Figure Description

[0074] To make the objectives, technical solutions, and advantages of the present invention clearer, the preferred embodiments of the present invention will be described in detail below with reference to the accompanying drawings, wherein:

[0075] Fig. 1 This is a block diagram of the vertical federated learning system described in this invention;

[0076] Fig. 2 This is a flowchart illustrating the intersection of multiple privacy sets as described in this invention. Detailed Implementation

[0077] The following specific examples illustrate the implementation of the present invention. Those skilled in the art can easily understand other advantages and effects of the present invention from the content disclosed in this specification. The present invention can also be implemented or applied through other different specific embodiments, and various details in this specification can be modified or changed based on different viewpoints and applications without departing from the spirit of the present invention. It should be noted that the illustrations provided in the following embodiments are only schematic representations of the basic concept of the present invention. Unless otherwise specified, the following embodiments and features can be combined with each other.

[0078] It is to be noted that the drawings provided in the following embodiments only schematically illustrate the basic concepts of the present application, and only the components related to the present application are shown in the drawings, not the number, shape and size of the components when actually implemented, and the actual implementation of each component can be a random change, and the component layout pattern can be more complex.

[0079] In the following description, a large number of details are discussed to provide a more thorough explanation of the embodiments of the application, however, it is obvious to those skilled in the art that the embodiments of the application can be implemented without these specific details, and in other embodiments, the known structures and devices are shown in the form of block diagrams rather than in the form of details, to avoid making the embodiments of the application difficult to understand.

[0080] Please refer to Figs. 1-2 The present application provides a longitudinal federated learning data alignment method based on multi-party private set intersection, which is suitable for data alignment and privacy protection in longitudinal federated learning environment. By introducing a trusted third-party auditing agency, combined with zero-knowledge proof and homomorphic encryption technology, the method realizes the legality verification of user ID, compliance supervision of intersection calculation and security guarantee of joint training under the premise of ensuring the privacy of each participant's data, so as to ensure the fairness, security and privacy protection of the data cooperation process.

[0081] As Fig. 1 The longitudinal federated learning system block diagram described in the present application includes ID sample alignment in the first stage and model training in the second stage.

[0082] As Fig. 2 The multi-party private set intersection flowchart described in the present application performs secure multi-party ID set intersection operation between the client and the server.

[0083] In order to achieve the above purpose, the present application provides the following technical solutions:

[0084] S1: protocol initialization stage:

[0085] Suppose there are P1,...,P t Each party holds a private data set S1,S2,...,S t , each set contains n i elements, and the goal of the protocol is to obtain the intersection through secure calculation: Ensure that each party can only train on the intersection users. Among the participants, P1 to P t-1 are called clients, P t is the server side, and TPA is the auditing agency responsible for the whole process, and TA is the trusted agency for ID registration and signature.

[0086] ID registration: each participant P i Collects its users' IDs Sends to TA, TA performs detailed verification on each ID received, including but not limited to checking whether the format of the ID is in accordance with the provisions, whether there are duplicate IDs, whether it conflicts with other registered IDs, etc. Verification methods can use database queries, comparison with known legal ID library, etc. For the ID that passes the verification, TA issues a certificate Cert(ID) containing a signature. The signature process uses asymmetric encryption algorithm, TA uses its private key to sign the ID related information (such as ID itself, issuance time, validity period, etc.). The certificate should also contain the public key information of TA, in order to verify the signature later. TA sends the issued certificate Cert(ID) back to the corresponding participant P i . Participant P i Preserves the certificate properly for use in the subsequent user ID verification stage.

[0087] S2: User ID verification stage:

[0088] Before the multi-party private set intersection calculation stage, TPA first verifies the authenticity of the user IDs submitted by each party to prevent any party from obtaining more data by forging user IDs. In this stage, each party uses zero-knowledge proof to prove the legitimacy of its user IDs.

[0089] First, generate a hash: before performing user ID hash calculation, the participant binds the certificate Cert(ID i ) it holds with the corresponding user ID set ID i . The binding method can use cryptographic hash chain or digital envelope technology to ensure the integrity and relevance of the certificate and ID set. Then the bound result is processed together with the user ID set. Then the user ID hash calculation, each participant P i hashes its user ID set to get the hash set: Where h is a one-way hash function, which ensures that TPA cannot restore the original value of the user ID.

[0090] Then generate zero-knowledge proof: in order to prove that each h(ID i,j ) in H i is a legal user ID hash value and the corresponding ID has a valid certificate issued by a trusted agency, each participant P i generates a zero-knowledge proof π i,j for each hash value, so that: π j = ZKP(h(ID j), AC). Where AC represents the attribute that the ID satisfies the authenticity requirement, the ID is issued by a trusted certification authority, and contains a signature to avoid fake ID. To achieve zero-knowledge proof generation, we use a zero-knowledge proof process based on the Schnorr protocol: assume that each user ID corresponds to a hash value h(ID i,j ) has a secret x j from the user ID's signature key, which satisfies the following relationship: where g is the generator and p is a large prime number, ensuring the difficulty of the discrete logarithm problem. The prover wants to prove that it knows x j such that holds, but does not directly reveal x j . In combination with the relevant information in the certificate Cert(ID i ), including the hash value of the certificate, the signature, etc., to ensure that the entire proof process can reflect the authenticity of the ID and the validity of the certificate. The participant P i submits the hash set H i , the corresponding zero-knowledge proof {π i,j}, and the bound certificate and ID set to the TPA.

[0091] Finally, the TPA verifies the zero-knowledge proof: the TPA receives the hash set H i submitted by each participant P i , the corresponding zero-knowledge proof set {π i,j}, and the bound certificate and ID set, and performs the following verification steps: first, use the trusted authority's public key (obtained from the certificate) to verify the signature of the certificate Cert(ID i ) and check whether the certificate is within the valid period and whether the ID information in the certificate is consistent with the submitted ID set. If the certificate verification fails, directly determine that the ID set submitted by the participant is invalid, and mark it as a violation; if the certificate verification passes, continue to execute the original zero-knowledge proof verification algorithm. Then verify the zero-knowledge proof: for each h(ID i,j ) ∈ H i , the TPA uses the verification algorithm Verify to check whether the corresponding proof π i,j is valid: Verify(h(ID i,j ), π i,j ) = True, if the verification passes, record h(ID i,j ) as a legal user ID; otherwise, mark it as invalid. Record the legal user ID hash set, after verification, the TPA records each participant's legal user ID hash set as: D verified,i = {h(ID i,j ) | Verify(h(ID i,j ), πi,j ) = True}, this set will be used for the subsequent intersection calculation.

[0092] S3: Multi-Party Private Set Intersection (MPSI) computation phase:

[0093] After the user ID verification is completed, the TPA uses the verified user ID hash set to perform intersection calculation, ensuring that only the real user IDs of each party are included in the intersection set, as shown in Fig. 2 .

[0094] First, the input of MPSI and the generation of encrypted inverse Bloom filter: 1. Input: Each client P i holds a shared decryption key sk i , which belongs to an additive homomorphic threshold encryption scheme with a zero decryption algorithm (ShDec0). The public key pk is visible to all parties. 2. Initialization: The server P t randomly selects a set of hash functions and sends them to the client P i , where 1 ≤ i ≤ t-1. 3. Local encrypted inverse Bloom filter generation: Each client P i performs the following steps to generate an encrypted inverse Bloom filter, thereby achieving privacy-protected user ID encryption: calculates the Bloom filter BF i of its user ID set S i , obtains the inverse Bloom filter IBF i of the Bloom filter, encrypts each element in IBF i to obtain the encrypted inverse Bloom filter and sends it to the server P t .

[0095] Then, MPSI computation is performed: The server P t performs the following steps to calculate the intersection user set: for each element y t in the user ID set S j held by the server, calculates k hash values h d (y j ), and for each hash value h d (y j ) finds the value in the inverse Bloom filter IBF i of each client: and j ∈ {1,...,n t}. The sum of the ciphertexts is calculated and re-randomized to ensure privacy: The re-randomization operation aims to break the determinism of homomorphic encryption and avoid information leakage. The server distributes the result to any a client, and requests them to decrypt each e j , usually

[0096] Compliance check: Each client P i computes its decryption share sh i,j and feeds it back to the server. Specifically as follows:

[0097] (1) The client first randomizes e j , sends the randomized e back to the server, and the server combines them into e and sends them to each client.

[0098] (2) The server aggregates the decryption shares sh i,j fed back by the clients, and finally forms the set of decryption shares sh 1,j ,...,sh t-1,j .

[0099] TPA verifies the decryption process: The TPA supervises the decryption feedback process of the clients, ensures that all feedback is sent through a secure channel, and prevents the server or the client from interfering with the calculation results by manipulating the feedback data. The TPA can randomly check the feedback decryption shares of the clients to ensure compliance.

[0100] (3) The server decrypts using the combination algorithm. For each j∈{1,...,n t}, the server calculates: Dec(e j )←Comb(sh 1,j ,...,sh t-1,j ). If the decryption result is zero (i.e. Dec(e j )=0), it means that y j is in the user ID set of all participants, and the server adds y j to the intersection set S={y j}∪S. Otherwise, y j is discarded.

[0101] Final intersection user set output: The server P t outputs the intersection set S and submits the result to the TPA for final confirmation. After the TPA verifies the intersection result, it sends the compliant intersection set to each party for subsequent federated training.

[0102] S4: Encryption verification and homomorphic encryption check in the federated training phase:

[0103] In the federated training phase, TPA ensures that each party only trains on the complete intersection user set S by cryptographic verification and dynamic homomorphic encryption check, preventing the case of less-set intersection training or using non-intersection users.

[0104] First, the cryptographic verification mechanism: before each round of training, TPA requires each party to submit the encrypted hash set of user IDs for training S to verify the compliance of training data. The encrypted hash generation: the participating party hashes and encrypts each user ID in its rth round of training user set to generate the set: where E(·) denotes the encryption operation.

[0105] Then the intersection consistency verification of TPA: TPA holds the encrypted hash set E(S) of the complete intersection user set S. At the beginning of each round of training, TPA verifies: If the verification is passed, it means that the participating party trains on the complete intersection user; otherwise, TPA records the violation.

[0106] Then the dynamic homomorphic encryption check: TPA uses dynamic homomorphic encryption check technology to prevent participating parties from using non-intersection user data in some rounds. Randomly generate checkpoints: TPA generates checkpoints at random rounds in the training process, requiring each participating party to resubmit the encrypted training data set to ensure the consistency of training. Homomorphic encryption verification: TPA uses homomorphic encryption technology at the checkpoint to verify whether it is consistent with E(S), ensuring that each round of training data comes from the complete intersection.

[0107] Finally, the training phase. After determining the common entities, each party can use the data of these common entities to collaboratively train a machine learning model. The training process can be divided into the following four steps: 1, the trusted coordinator creates a key pair and sends the public key to the client and the server; 2, the client and the server encrypt and exchange intermediate results, which are used to help calculate the gradient and loss value; 3, the client and the server calculate the encrypted gradient and add additional masks respectively, and the server also calculates the encrypted loss, and the client and the server send the encrypted results to the trusted coordinator; 4, the trusted coordinator decrypts the gradient and loss information, and sends the results back to the client and the server. The client and the server remove the mask on the gradient information, and update the model parameters according to the gradient information.

[0108] S5: violation handling and reward and punishment mechanism:

[0109] In this scheme, the TPA is responsible for overseeing the behavior of each participant to ensure compliance with the agreement and the authenticity of the data. When detecting a participant's violation of the rules (such as fake user ID or improper use of intersection data), the TPA will handle it according to the predetermined reward and punishment mechanism:

[0110] First, the violation detection, the TPA uses zero-knowledge proof and encryption verification technology in each key step to check the compliance of each party regularly.

[0111] Then the punishment measures, for the participants who have confirmed the violation, the TPA will take the following measures: model weight reduction: reduce its contribution weight in the federal model. Economic penalties: impose economic penalties on the violating party. Cooperation restrictions: in the case of serious violation, suspend its participation qualification in federated learning.

[0112] Finally, the reward measures, for the compliant participants, the TPA will issue a compliance certificate and give appropriate rewards to encourage each party to follow the agreement.

[0113] Finally, it should be pointed out that the above embodiments are only used to illustrate the technical solutions of the present application and are not limiting. Although the present application has been described in detail with reference to the preferred embodiments, those skilled in the art should understand that the technical solutions of the present application can be modified or replaced by equivalents without departing from the spirit and scope of the present application, and they should be covered in the scope of the claims of the present application.

Claims

1. A multi-participant longitudinal federated learning method based on data alignment and privacy protection, characterized in that: Includes the following steps: S1: Protocol initialization phase: Initialize the protocol, and the trusted authority (TA) registers and signs the ID; S2: User ID Verification Phase: Each participant uses zero-knowledge proofs to prove the legitimacy of its user ID; S3: Multi-party private set intersection calculation stage: The third-party auditing agency TPA uses a verified set of user ID hashes to perform intersection calculation, ensuring that the intersection set contains only the real user IDs of each party; S4: Encryption Verification and Homomorphic Encryption Check Phase: TPA ensures that all parties only use encryption verification and dynamic homomorphic encryption checks within the complete intersection set of users. Training was conducted on [the subject]. S5: Violation Handling and Reward / Penalty Mechanism Stage: When a violation is detected by a participant, the TPA will handle it according to the predetermined reward / penalty mechanism; Step S2 specifically includes the following steps: S21: Generate User ID Hash: First, use the user's certificate... With the corresponding set of user IDs Perform the binding; then, combine the bound result with the user ID set to perform user ID hash calculation for each participant. Set its user IDs Perform a hash transformation to obtain a hash set: in It is a one-way hash function, ensuring that TPA cannot restore the original value of the user ID; S22: Generating Zero-Knowledge Proofs: Participants Generate zero-knowledge proofs for each hash value , so that: Here, AC indicates that the ID meets the authenticity requirements. A zero-knowledge proof process based on the Schnorr protocol is adopted: assuming that each user ID corresponds to a hash value... There is a secret The signing key derived from the user ID satisfies the following relationship: in It is a generator. It is a large prime number; The prover wants to prove that he knows , making Established, but not directly disclosed. Combined with certificates The relevant information in the document ensures that the entire verification process reflects the authenticity of the ID and the validity of the certificate; S23: Participants hash set The corresponding zero-knowledge proof The bound certificate and ID set are submitted together to the TPA; S24: Verify zero-knowledge proofs: TPA receives information from each participant. Submitted hash set The corresponding set of zero-knowledge proofs And the bound certificate and ID set, and perform the following verification steps: First, obtain the trusted authority's public key from the certificate and verify the certificate. The system checks the validity of the signature, the validity of the certificate, and the consistency between the ID information in the certificate and the submitted ID set. If the certificate verification fails, the submitted ID set of the participant is deemed invalid and marked as a violation. If the certificate verification passes, the system verifies the zero-knowledge proof for each... TPA uses a verification algorithm Check the corresponding proof Is it effective? If the verification passes, then Record a valid user ID; otherwise, mark it as invalid. S25: Record the set of valid user ID hashes: After verification, the TPA will record the set of valid user ID hashes for each participant; Step S3 specifically includes the following steps: S31: MPSI input is generated using an encrypted inverse Bloom filter and sent to the server. ; S32: MPSI Calculation: The server first calculates the hash value for each element in the user ID set and looks for a match in the client's cryptographic inverse Bloom filter; the server calculates the sum of the ciphertexts and re-randomizes them; the server distributes the encryption results to selected clients, and the clients decrypt them and send them back to the server; the server summarizes the decryption results, forms an intersection set, submits it to TPA for confirmation, and then uses it for federated training.

2. The multi-participant longitudinal federated learning method based on data alignment and privacy protection according to claim 1, characterized in that: The protocol initialization in step S1 includes: The agreement contains Each party holds a collection of private data. Each set contains The goal of the protocol is to obtain the intersection of the given elements through secure computation. ; Ensure that each party can only train on the intersection of users; among the participating parties, arrive Called the client, On the server side, TPA acts as the review body and is responsible for overseeing the entire process, while TA acts as a trusted body to register and sign the ID. The trusted authority (TA) registers and signs the ID, specifically including: Each participant its user ID set The ID is sent to TA, who verifies each received ID. For verified IDs, TA uses an asymmetric encryption algorithm and its private key to sign the ID-related information, thus authorizing the participants. Issue a certificate containing the signature and TA public key information. and send it back to the corresponding participants. save.

3. The multi-participant longitudinal federated learning method based on data alignment and privacy protection according to claim 1, characterized in that: Step S31, the generation of the MPSI input and encrypted inverse Bloom filter, includes the following steps: S311: Input: per client - Holding a shared decryption key The key belongs to an additive homomorphic threshold encryption scheme with the zero-decryption algorithm ShDec0; the public key Visible to all parties; S312: Initialization: Server Randomly select a set of hash functions And send it to the client; S313: Locally Encrypted Inverse Bloom Filter Generation: Each client performs the following steps to generate an encrypted inverse Bloom filter, thereby achieving privacy-preserving user ID encryption: Calculate its user ID set Bloom filters Obtaining a reverse Bloom filter from a Bloom filter ,right Each element in the algorithm is encrypted to obtain an encrypted inverse Bloom filter, which is then sent to the server. .

4. The multi-participant longitudinal federated learning method based on data alignment and privacy protection according to claim 1, characterized in that: In step S32, the server side Perform the following steps to calculate the intersection set of users: The set of user IDs held by the server Each element in ,calculate hash value And for each hash value Anti-Bloom filters on each client Lookup value: ， Calculate the sum of the ciphertexts and rerandomize: The server will display the results. Distribute to Any client Each client, and requests them for each Decrypt; Compliance checks: for each client Calculate its decryption share And this feedback is sent to the server, as follows: (1) The client first... Perform randomization processing, and then randomize the result. Send it back to the server, and the server combines it into And send it to each client; (2) The server summarizes the decryption shares reported by the client. This ultimately forms the set of decrypted shares. ; TPA verifies the decryption process: TPA monitors the client's decryption feedback process to ensure that all feedback is sent through a secure channel and to prevent the server or client from interfering with the calculation results by manipulating the feedback data; TPA randomly checks the client's feedback decryption share to ensure that the decryption process is compliant; (3) The server uses a combination algorithm for decryption, for each The server uses a combinatorial algorithm to calculate: ; If the decryption result is zero, that is , then it means From the set of user IDs of all participants, the server will Add to intersection set If correct, discard. ; The final intersection set of users is output: Server-side The final output is the intersection set. The results are then submitted to the TPA for final confirmation; after the TPA verifies the intersection results, it sends the compliant intersection set to all parties.

5. The multi-participant longitudinal federated learning method based on data alignment and privacy protection according to claim 1, characterized in that: Step S4 specifically includes the following steps: S41: Encrypted Verification Mechanism: Before each round of training begins, TPA requires all parties to submit a set of encrypted hashes of the user IDs used for training. To verify the compliance of the training data; each party generates a set of cryptographic hashes, and TPA verifies whether these sets are consistent with the known complete intersection set; if the verification passes, it indicates that the parties are training on the correct intersection users; if it fails, TPA will record the violation. S42: Dynamic Homomorphic Encryption Check: TPA employs dynamic homomorphic encryption check technology to prevent participants from using non-overlapping user data in certain rounds; firstly, checkpoints are randomly generated: TPA generates checkpoints in random rounds during training, requiring each participant to resubmit encrypted training data sets. Then, homomorphic encryption verification: TPA uses homomorphic encryption at checkpoints to verify... Whether or not Consistency is ensured, guaranteeing that the training data in each round comes from the complete intersection; S43: Training Phase: After identifying the shared entities, the parties use the data from these shared entities to collaboratively train a machine learning model.

6. The multi-participant longitudinal federated learning method based on data alignment and privacy protection according to claim 5, characterized in that: The training phase described in step S43 includes the following steps: S431: The trusted coordinator creates a key pair and sends the public key to the client and server; S432: The client and server encrypt and exchange intermediate results, which are used to help calculate gradients and loss values; S433: The client and server calculate the encryption gradient and add additional masks respectively. The server calculates the encryption loss. The client and server send the encryption results to the trusted coordinator. S434: The trusted coordinator decrypts the gradient and loss information and sends the results back to the client and server; the client and server remove the masking on the gradient information and update the model parameters based on this gradient information.

7. The multi-participant longitudinal federated learning method based on data alignment and privacy protection according to claim 1, characterized in that: Step S5 specifically includes the following steps: Compliance Detection: TPA uses zero-knowledge proofs and cryptographic verification technologies in each key step to regularly check the compliance of all parties. Penalties: For parties confirmed to have violated regulations, TPA will take the following measures: (1) Reduce model weights: reduce their contribution weights in the federated model; (2) Economic penalties: Imposing economic penalties on the violator; (3) Restrictions on cooperation: In cases of serious violations, their eligibility to participate in federal learning will be suspended; Incentive measures: For compliant participants, TPA will issue compliance certificates and provide appropriate rewards to encourage all parties to follow the agreement.

Images