An information data operation processing system based on a secure isolation gateway

Abstract

The application discloses an information data operation processing system based on a security isolation gateway, and relates to the technical field of data communication.The system comprises a security isolation gateway, a global side subsystem and N participant side subsystems, wherein N is a positive integer; the security isolation gateway is connected between the global side subsystem and each participant side subsystem and is configured to establish a controlled one-way data transfer channel between the two; the global side subsystem comprises a global coordination module, a trusted verification module and a security aggregation module; and each participant side subsystem comprises a trusted execution module.The application solves the technical problem that the privacy protection of the existing information data processing process depends on a complex cryptography protocol, is inefficient and is difficult to exclude malicious or low-quality updates, and affects the security and efficiency of cross-domain information processing, and achieves the technical effects of simplifying privacy protection, efficiently excluding malicious updates and improving the security and efficiency of cross-domain information processing by using the security isolation gateway.

Description

Technical Field

[0001] This invention relates to the field of data communication technology, and more specifically to an information data processing system based on a security isolation gateway. Background Technology

[0002] In the field of modern information technology, with the explosive growth of data volume and the widespread application of artificial intelligence, the demand for cross-institutional data collaboration is increasing. However, data privacy and security issues have become key bottlenecks restricting such collaboration. Traditional privacy-preserving computation methods, such as federated learning, while protecting data privacy to some extent, still rely on complex cryptographic protocols, resulting in low computational efficiency and difficulty in large-scale deployment. Furthermore, existing technologies are insufficient in preventing malicious data injection and low-quality data updates, making it difficult to guarantee the accuracy and reliability of the global model, thus posing challenges in cross-domain collaboration involving sensitive data. Summary of the Invention

[0003] This application provides an information data processing system based on a secure isolation gateway, which solves the technical problems of existing information data processing processes, such as privacy protection relying on complex cryptographic protocols, low efficiency, difficulty in preventing malicious or low-quality updates, and impact on the security and efficiency of cross-domain information processing.

[0004] This application provides an information data processing system based on a secure isolation gateway. The system includes a secure isolation gateway, a global side subsystem, and N participating side subsystems, where N is a positive integer. The secure isolation gateway connects the global side subsystem and each participating side subsystem. Its hardware architecture is configured to support a unidirectional data transfer channel for sequential unidirectional transmission between the global side subsystem and the participating side subsystems. The global side subsystem includes a global coordination module, a trusted verification module, and a secure aggregation module. Each participating side subsystem includes a trusted execution module. The global coordination module generates a first synchronization packet containing global model parameters and dynamic verification rules, and transfers it unidirectionally to each participating side subsystem via the secure isolation gateway in a first unidirectional mode. The trusted execution module in each participating side subsystem verifies the first synchronization packet based on the dynamic verification rules upon receipt, and utilizes local privacy after successful verification. The data is used to train the global model parameters, generate local model updates and contribution proofs, and then unidirectionally transfer the local response packet containing the local model updates and contribution proofs back to the global side subsystem via the security isolation gateway in a second unidirectional mode. The security isolation gateway is configured to initiate the second unidirectional mode only after the data transmission in the first unidirectional mode is completed. The trusted verification module is used to arbitrate the contribution of the local response packets returned from each participating side subsystem, generating a contribution arbitration result. The secure aggregation module is used to perform weighted aggregation of the arbitrated local model updates based on the contribution arbitration result, generating a new generation of global model parameters, and generating and encoding the dynamic verification rules for the next round of verification based on the contribution arbitration result of this round. The global coordination module is also used to encapsulate the new generation of global model parameters and the re-encoded dynamic verification rules into a second synchronization packet to initiate the next iteration.

[0005] One or more technical solutions provided in this application have at least the following technical effects or advantages:

[0006] This application provides an information data processing system based on a secure isolation gateway, relating to the field of data communication technology. It achieves unidirectional data transmission between a global subsystem and multiple participating party subsystems through a secure isolation gateway. Combined with a trusted execution environment, it performs local model training and updates, employs contribution arbitration and weighted aggregation to generate next-generation global model parameters, and adaptively updates dynamic verification rules to ensure data privacy protection and the reliability of model updates. This solves the technical problems of existing information data processing processes, which rely on complex cryptographic protocols for privacy protection, resulting in low efficiency and difficulty in excluding malicious or low-quality updates, thus affecting the security and efficiency of cross-domain information processing. The system achieves the technical effect of simplifying privacy protection, efficiently excluding malicious updates, and improving the security and efficiency of cross-domain information processing by utilizing a secure isolation gateway. Attached Figure Description

[0007] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0008] Figure 1 A schematic diagram of an information data processing system based on a security isolation gateway is provided in this application embodiment;

[0009] Figure 2 This is a flowchart illustrating the process of an information data processing system based on a security isolation gateway, as provided in this application embodiment.

[0010] Explanation of reference numerals in the attached diagram: Security isolation gateway 10, global side subsystem 20, participant side subsystem 30, global coordination module 21, trusted verification module 22, security aggregation module 23, trusted execution module 31. Detailed Implementation

[0011] This application provides an information data processing system based on a secure isolation gateway, which solves the technical problems of existing information data processing processes, such as privacy protection relying on complex cryptographic protocols, low efficiency, difficulty in preventing malicious or low-quality updates, and impact on the security and efficiency of cross-domain information processing.

[0012] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this application.

[0013] It should be noted that the terms "first," "second," etc., in the specification and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or server that includes a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or modules not explicitly listed or inherent to such processes, methods, products, or devices.

[0014] Example 1, as Figure 1 As shown, this application provides an information data processing system based on a security isolation gateway, the system comprising:

[0015] The system comprises a security isolation gateway 10, a global side subsystem 20, and N participating side subsystems 30, where N is a positive integer. The security isolation gateway 10 is connected between the global side subsystem 20 and each participating side subsystem 30. Its hardware architecture is configured to support a unidirectional data transfer channel for sequential unidirectional transmission between the global side subsystem and the participating side subsystems. The global side subsystem includes a global coordination module 21, a trusted verification module 22, and a security aggregation module 23. Each participating side subsystem includes a trusted execution module 31.

[0016] It should be understood that in this embodiment, the security isolation gateway 10 acts as a bridge connecting the global side subsystem 20 and multiple participating side subsystems 30, responsible for establishing a controlled unidirectional data transmission channel. The gateway's design ensures that during the synchronous distribution phase, data and model flow can only occur from the global side subsystem 20 to the participating side subsystems 30, and during the response recovery phase, data and model flow can only occur from the participating side subsystems 30 to the global side subsystem 20, with no reverse transmission possible, thus ensuring data security and privacy protection. In this architecture, the gateway's physical isolation characteristic is crucial for achieving data security; by strictly controlling the direction of data flow, it avoids the risk of original data leakage or reverse analysis of the model.

[0017] The global subsystem 20 consists of three modules: a global coordination module 21, a trusted verification module 22, and a secure aggregation module 23. The main task of the global coordination module 21 is to generate a synchronization packet containing global model parameters and dynamic verification rules, and then transmit this packet unidirectionally to each participating subsystem 30 via a secure isolation gateway 10. This synchronization packet not only contains the current state of the global model but also the updated dynamic verification rules, forming the basis for multi-party collaborative training. The transmission of the synchronization packet ensures that all participants are always training and updating within a common model framework.

[0018] When a participating party's subsystem receives a synchronization packet, each party's trusted execution module 31 verifies the packet's content to ensure it conforms to global standards. If the verification passes, the participating party uses local privacy data to train the global model and generates local model updates and contribution proofs. The trusted execution module 31 ensures that the participating party's training data is not leaked to other parties or the global subsystem 20, thereby protecting the security of privacy data. The core of this application lies in utilizing the physical isolation characteristics of a secure isolation gateway, combined with the needs of privacy computing, to establish a unidirectional data flow mechanism. Through this mechanism, the transmission of data and models is always unidirectional, effectively preventing the risks of data leakage and model reverse engineering.

[0019] like Figure 2 As shown, the global coordination module 21 is used to generate a first synchronization package containing global model parameters and dynamic verification rules, and then unidirectionally transfers it to the subsystems of each participating party through the security isolation gateway 10 in a first unidirectional mode.

[0020] Optionally, the global coordination module 21 of this application serves as the task initiator of the entire system. Its core responsibility is to prepare and distribute the initial computational tasks and accompanying security policy framework for each round of federated learning iteration. Specifically, it is responsible for generating the first synchronization packet containing global model parameters and dynamic verification rules, and transmitting it unidirectionally to the participating subsystems 30 via the security isolation gateway 10. The global model parameters are the foundation of federated learning; they define the initial structure and weights of the model, providing a unified starting point for all participants. The dynamic verification rules are a verification mechanism used to verify the credibility of the local model updates submitted by the participants, thereby ensuring the security and reliability of the system.

[0021] Specifically, upon entering a new iteration cycle, the global coordination module 21 first retrieves and loads the global model parameters generated in the previous iteration from its internal or external persistent storage unit. These global model parameters refer to a set of encrypted numerical values ​​that fully defines the weights and biases of each layer of the current machine learning model and are the core objective that all participants need to collaboratively optimize. If the system is running for the first time, a standardized model initialization process can be executed to generate a set of initial model parameters with a basic structure.

[0022] Simultaneously, the global coordination module 21 proactively requests the security aggregation module 23, which also belongs to the global side subsystem 20, to obtain the dynamic verification rules specifically configured for the current round. These dynamic verification rules are a set of structured policy data and verification logic, which may include data digest codes generated by a specific cryptographic hash function for verifying model integrity, boundary constraints regarding the legal range of model parameter values, and baseline metrics and calculation methods for evaluating the effectiveness of participant contributions.

[0023] After successfully acquiring the two core data sets mentioned above, the global coordination module 21 enters the data encapsulation stage. It assembles the global model parameters and dynamic verification rules according to a predefined data packet format to generate the first synchronization packet. This first synchronization packet is used to reliably transmit the unified computational task and security contract from the global side to all distributed participating parties.

[0024] Next, the global coordination module 21 transmits the first synchronization packet unidirectionally in a first unidirectional mode through the security isolation gateway 10. The security isolation gateway 10 is a key component in the entire system ensuring data security and privacy protection. Transmitting data in the first unidirectional mode ensures that data can only flow in one direction, from the global side to the participating side, and cannot flow in the reverse direction. Specifically, the global coordination module submits the data stream of the first synchronization packet to the data transmission port of the connected security isolation gateway 10 through its integrated standard network socket interface. Upon receiving the data stream, the security isolation gateway 10, based on its pre-loaded access control list and protocol filtering policies (e.g., allowing only data from specific target ports and specific application layer protocols to pass), initiates its physical isolation exchange mechanism. This mechanism ensures that at any given time, data can only physically flow from the global side network to the participating side network, without any reverse electronic feedback path.

[0025] The data stream is securely written to the isolation buffer within the gateway and subsequently replicated unidirectionally or switched to the participant-side network. Finally, the first synchronization packet is reliably transmitted to each participant-side subsystem 30 registered and ready in the system. This unidirectional data transmission ensures that each participant can only receive the global model and dynamic verification rules, and cannot access the global model in reverse, effectively preventing data leakage and model reverse engineering risks.

[0026] The trusted execution module 31 in each participating subsystem is used to verify the first synchronization packet based on dynamic verification rules after receiving it. After successful verification, the module uses local privacy data to train the global model parameters, generate a local model update and contribution proof, and then uses the security isolation gateway to unidirectionally transfer the local response packet containing the local model update and contribution proof back to the global subsystem in a second unidirectional mode. The security isolation gateway is configured to start the second unidirectional mode only after the data transmission in the first unidirectional mode is completed.

[0027] Furthermore, the trusted execution module 31 is also configured to perform the following steps:

[0028] The integrity and origin of the first synchronization package are verified according to dynamic verification rules. After the verification is successful, the global model parameters in the first synchronization package are trained using local privacy data in a trusted execution environment to generate the local model update and the contribution proof.

[0029] Specifically, the trusted execution module 31 in each participant-side subsystem 30 of this application is a key component for achieving data privacy protection and collaborative learning. When the participant-side subsystem 30 receives the first synchronization packet sent by the global coordination module 21 through the security isolation gateway 10, the trusted execution module 31 first rigorously verifies the integrity and origin of the first synchronization packet according to dynamic verification rules. Specifically, the verification steps include integrity verification and origin verification. Integrity verification checks whether the data in the synchronization packet has been encrypted or hashed to ensure that the data has not been tampered with or lost during transmission. If the data is incomplete or corrupted, the module will refuse to continue operation to ensure the accuracy of model training. Origin verification verifies whether the source of the synchronization packet is reliable, ensuring that the data indeed comes from the global side subsystem 20 and not from a malicious or unauthorized source. Typically, this process is performed through digital signatures, timestamps, or other authentication mechanisms to ensure that the received synchronization packet has not been forged or tampered with.

[0030] After successful verification, the trusted execution module 31 enters the model training phase. Since the privacy data held by each participating subsystem 30 should not be disclosed, the trusted execution module 31 performs subsequent computations within a trusted execution environment. A trusted execution environment is a hardware-isolated execution environment that prevents external programs or unauthorized entities from accessing data. Through this environment, the local privacy data of the participating subsystem 30 participates in the model training process under secure isolation, thereby ensuring data privacy and security. Specifically, the trusted execution module 31 uses local privacy data to train the global model parameters contained in the first synchronization package. This process is a standard machine learning training process, where the participating subsystem 30 fine-tunes or optimizes the global model based on its local dataset to improve the model's predictive ability. At this time, the privacy data used will not be leaked to other participants or the global subsystem, ensuring that the participants' local data is adequately protected.

[0031] After local training, the trusted execution module 31 generates two important results: a local model update and a contribution proof. The local model update refers to the changes or adjustments to the model parameters generated during training, reflecting the improvements made to the global model by participating parties based on local data. The contribution proof is used to demonstrate the degree of contribution made by the participating party in this model update, ensuring that each party's contribution can be accurately evaluated by the global subsystem. Finally, the generated local model update and contribution proof are encapsulated into a local response packet and transmitted unidirectionally back to the global subsystem 20 via the security isolation gateway 10 in a second unidirectional mode. At this time, the data in the local response packet remains encrypted, and can only be transmitted unidirectionally from the participating party's subsystem back to the global subsystem via the second unidirectional mode. Furthermore, the security isolation gateway is configured to activate the second unidirectional mode only after the data transmission in the first unidirectional mode is completed. In other words, when performing data transfer operations, within the same iteration cycle, one-way data transfer from the global side to all participants is established and completed first. Only after this transfer process is completed can one-way data transfer from each participant to the global side be established and executed, thereby avoiding the risk of data leakage or malicious tampering.

[0032] Furthermore, when verifying the integrity and origin of the first synchronization packet according to the dynamic verification rules, the trusted execution module 31 is also used to perform the following steps:

[0033] The pre-generated data digest code is extracted from the dynamic verification rules, and the same digest generation function is executed on the global model parameters in the first synchronization packet to obtain the real-time digest code. The real-time digest code and the data digest code are compared bit by bit. If they are completely consistent, the integrity verification is deemed to have passed. As a parallel and independent verification step, the attached transmission metadata is parsed from the first synchronization packet, and it is verified whether the transmission metadata contains a unique channel identifier and a digital seal embedded by the security isolation gateway during the transfer. If the channel identifier matches the preset identifier in the dynamic verification rules, and the digital seal passes the asymmetric cryptography verification, the source verification is deemed to have passed.

[0034] Optionally, when verifying the integrity and origin of the first synchronization packet based on dynamic verification rules, the trusted execution module 31 further refines the verification process. First, the trusted execution module 31 extracts a pre-generated data digest code from the dynamic verification rules. This is a value processed by a hash function, representing a unique identifier for the global model parameters in the synchronization packet. It can be calculated from the global model parameters using a specific digest generation function, such as SHA-256. Next, the trusted execution module 31 executes the same digest generation function on the global model parameters in the first synchronization packet to generate a real-time digest code. The purpose of this digest function is to convert the global model parameters in the synchronization packet into a fixed-length hash value to verify whether the data has been tampered with during transmission.

[0035] Next, the trusted execution module 31 compares the generated real-time digest code with the pre-generated data digest code extracted from the dynamic verification rules, bit by bit. If the comparison results are completely consistent, it means that the global model parameters in the synchronization package have not changed, the verification passes, and the integrity of the data is confirmed. If the two are inconsistent, the integrity verification will be judged as a failure, and the trusted execution module 31 will stop subsequent operations to prevent erroneous data from affecting model training.

[0036] After the integrity verification is passed, the trusted execution module 31 further verifies the origin of the first synchronization packet. It parses the accompanying transmission metadata from the first synchronization packet. Transmission metadata typically contains information about the data transmission, such as the sender's identity, timestamp, and other control information related to data flow. The trusted execution module 31 will focus on checking whether this transmission metadata contains a unique channel identifier and a digital seal embedded by the security isolation gateway 10 during data transmission. The channel identifier is a unique identifier used to indicate the specific secure channel through which the data passes during transmission, while the digital seal is a data signature generated by the global side subsystem 20 and encrypted using asymmetric encryption technology, verifying the legitimacy of the data source.

[0037] Next, the trusted execution module 31 compares the parsed channel identifier with the preset identifier in the dynamic verification rules. If they match, it means the synchronization packet was transmitted on the correct secure channel. If the match fails, it means the data source is not as expected, and the verification fails. Furthermore, the trusted execution module 31 also verifies the legitimacy of the digital seal using asymmetric cryptography. The digital seal is encrypted using the private key of the global side subsystem, and the trusted execution module 31 decrypts it using the corresponding public key and verifies the validity of the signature. If the verification passes, it means the synchronization packet indeed comes from the trusted global side subsystem 20.

[0038] Only after data integrity verification and source verification pass will the trusted execution module 31 continue with subsequent operations, such as training global model parameters using local privacy data and generating local model updates and contribution proofs. This process ensures the security and authenticity of all transmitted data during transmission, preventing the introduction of malicious data or tampered information.

[0039] Furthermore, when the trusted execution module 31 trains the global model parameters in the first synchronization package using local privacy data within the trusted execution environment and generates a local model update, it also performs the following steps:

[0040] Within a closed computing environment, the local privacy dataset is divided into multiple batches. For each batch of data, the computation graph defined by the global model parameters is sequentially input, and forward propagation is performed to obtain the predicted output. The loss value is calculated based on the predicted output and the true label. Backpropagation is performed to calculate the gradient change of each parameter in the global model parameters relative to the loss value. After all batches of data have been processed, the gradient changes of all batches are summarized, and the overall adjustment of the global model parameters is calculated as the local model update.

[0041] In one possible embodiment of this application, when training the global model parameters in the first synchronization package using local privacy data, the trusted execution module 31 operates within a closed computing environment to ensure the security of privacy data and the training process.

[0042] First, the trusted execution module 31 divides the local privacy dataset into multiple batches to accommodate batch processing and improve computational efficiency. This process involves splitting the large-scale dataset into smaller data blocks, ensuring that each batch contains a relatively uniform amount of data, which facilitates control over memory usage and optimization of training speed during computation. During the batching process, data privacy is protected; data within each batch is used only within the trusted execution environment, avoiding the risk of data leakage.

[0043] Next, for each batch of data, the trusted execution module 31 sequentially inputs the data into the computation graph defined by the global model parameters. The computation graph is the mathematical representation of the neural network model; it defines how data is computed and transformed through different layers and nodes. After inputting the data, a forward propagation operation is performed, whereby the data travels from the input layer through the various hidden layers of the neural network, ultimately producing a prediction output—the model's prediction of the input data based on the current global model parameters. This prediction can be used for subsequent loss calculations. The purpose of forward propagation is to process the input data through the model and generate prediction results that are compared with the actual labels.

[0044] Next, the trusted execution module 31 calculates the loss value based on the predicted output and its corresponding true label. The true label is a predefined correct answer from the local privacy data, used to measure the accuracy of the model's prediction. A loss function quantifies the difference between the model's prediction and the true label. Commonly used loss functions include mean squared error and cross-entropy loss. By calculating the loss value, the model's performance on the current batch of data can be evaluated, providing a basis for subsequent parameter adjustments. The smaller the loss value, the more accurate the model's prediction; conversely, the larger the loss value, the more necessary the model needs further optimization.

[0045] After obtaining the loss value, the trusted execution module 31 performs backpropagation. Backpropagation is an algorithm based on the chain rule, used to calculate the gradient change of each parameter in the global model parameters relative to the loss value, to determine the contribution of each parameter to the loss value. For example, starting from the loss value, backpropagation calculates the gradient of each parameter layer by layer along the reverse path of the computation graph, passing the gradient of the loss value from the output layer back to the input layer, and calculating the gradient change of each network parameter (such as weights, biases, etc.) relative to the loss value. These gradient changes indicate how to adjust the model parameters to reduce the loss value, thereby optimizing the model.

[0046] After all batches of data have been processed, the trusted execution module 31 aggregates the gradient changes from all batches to calculate the overall adjustment of the global model parameters. In other words, since each batch of data generates a set of gradient changes, these gradient changes need to be aggregated to obtain the overall adjustment of the global model parameters. The aggregation process can use a weighted average of the gradient changes from each batch or other aggregation operations to ensure that the overall adjustment comprehensively reflects the adjustment requirements of all batches of data for the model parameters. Local model updates represent improvements made by participants to the global model parameters, reflecting the contribution of local privacy data to the global model. In this way, participants can provide valuable update information for the optimization of the global model while protecting their local privacy data.

[0047] Furthermore, when generating the contribution proof, the trusted execution module 31 is also used to perform the following steps:

[0048] Record the loss value during training and calculate the relative decrease rate of the loss from the initial value to the final value; perform feature analysis on the local privacy dataset and calculate the difference measure between its data distribution and the preset general reference distribution; perform statistical analysis on the overall adjustment amount and calculate its numerical norm; input the relative decrease rate, the difference measure and the numerical norm into the preset contribution quantification function to calculate and generate the contribution proof.

[0049] Optionally, when generating contribution proofs, the trusted execution module 31 also needs to perform the following detailed steps to ensure that the contribution proofs accurately reflect the participants' contributions to the global model.

[0050] First, the trusted execution module 31 records the loss value for each batch during training. These loss values ​​are obtained after the model calculates the data for each batch and reflect the model's prediction error on that batch of data. By calculating the relative decrease rate of the loss value from the initial value (i.e., the loss value at the start of training) to the final value (i.e., the loss value at the end of training), the degree of improvement of the model during training can be quantified. For example, by dividing the difference between the initial loss value and the final loss value by the initial loss value, the reduction in the loss value during training can be quantified, thereby reflecting the improvement in model performance.

[0051] Secondly, the trusted execution module 31 performs feature analysis on the local privacy dataset, calculates the data distribution of the local privacy dataset, and compares it with a preset general reference distribution, calculating a difference measure between the two distributions. The general reference distribution is a predefined model representing a typical data distribution and can be used as a benchmark for comparison. Commonly used difference measures include KL divergence or Jensen-Shannon divergence. These difference measures reflect the uniqueness of the local dataset, i.e., the degree of deviation between the local data and the general data distribution, thus providing a basis for assessing contribution characteristics.

[0052] Next, the trusted execution module 31 performs statistical analysis on the overall adjustment amount and calculates its numerical norm. The overall adjustment amount refers to the combined change of all parameters during the local model update process, while the numerical norm measures the overall magnitude of these changes, typically using a norm or other forms of numerical standard. Commonly used norms include the L1 norm (the sum of the absolute values ​​of all elements) or the L2 norm (the square root of the sum of the squares of all elements). By calculating the numerical norm of the overall adjustment amount, the trusted execution module 31 can quantify the overall contribution of local training to the global model parameters.

[0053] Finally, the trusted execution module 31 inputs the relative decline rate, difference metric, and numerical norm into a predefined contribution quantization function to calculate the contribution proof. The contribution quantization function is a predefined mathematical model that generates the contribution proof based on the three input metrics. This function can be a simple linear combination or a complex nonlinear model, with the specific form designed according to actual needs. Through this process, the trusted execution module 31 can generate a contribution proof for each participant, indicating that participant's contribution to the global model optimization during this training.

[0054] The generated contribution proof will be encapsulated in the local response packet along with the local model update and transmitted unidirectionally back to the global side subsystem 20 via the secure isolation gateway 10. This proof not only helps the global side subsystem evaluate the role of each participant in model training, but also ensures the transparency and fairness of the training process, avoiding unfairness or bias among participants.

[0055] Furthermore, when the trusted execution module 31 executes the following steps to unidirectionally transfer the local response packet containing the local model update and contribution proof back to the global side subsystem through the security isolation gateway:

[0056] After receiving the local response packet, the sending agent of the security isolation gateway performs a content compliance check on the data in the packet according to the content filtering strategy specifically defined for the model update data structure. When the content compliance check passes, the data in the packet is converted into an intermediate format and the physical isolation switch is triggered to cache the data in the isolation storage area. After the physical isolation switch is disconnected, the receiving agent of the security isolation gateway reads the data from the isolation storage area and forwards it to the trusted verification module.

[0057] It should be understood that when the trusted execution module 31 executes the unidirectional transfer of the local response packet containing the local model update and contribution proof back to the global side subsystem through the security isolation gateway, it needs to perform the following detailed steps to ensure the security and compliance of the data during the transmission process.

[0058] First, after the trusted execution module 31 generates a local response packet containing local model updates and contribution proofs, this response packet is sent to the sending agent of the security isolation gateway. Upon receiving the local response packet, the sending agent performs a content compliance check on the data within the packet according to a predefined content filtering policy. The content filtering policy includes checking the data format, the legality of the content, and whether it contains any potential security risks, preventing malicious or non-compliant data from entering the system. The content compliance check includes verifying the data format, data type, data length, etc., ensuring that the data structure of the response packet is complete and conforms to the system's expected specifications. If the data in the packet fails the content compliance check, the packet will be discarded or marked as invalid, the data will be rejected for transmission, and an alarm may be triggered or the trusted execution module 31 may be notified to regenerate the data.

[0059] Once the content compliance check passes, the sending agent converts the data within the packet into an intermediate format. This intermediate format is a standardized data format used for data transmission between the sending and receiving ends of a security isolation gateway. This format conversion ensures data compatibility and consistency during transmission, while also facilitating further security checks and processing.

[0060] Subsequently, the sending agent triggers a physical isolation switch, caching the data in an isolated storage area. A physical isolation switch is a hardware mechanism used to ensure data is isolated from the external environment during transmission, preventing unauthorized access or tampering. Once data passes through the physical isolation switch, it is cached in the isolated storage area, ensuring that the data is not subject to external interference or leakage within this area.

[0061] After the physical isolation switch is disconnected, the receiving agent of the security isolation gateway will read data from the isolation storage area. At this time, due to the effectiveness of the physical isolation switch, the receiving agent can only read data that has been filtered and cached by the security isolation gateway from the isolation storage area, ensuring data integrity and transmission security. The receiving agent further processes the read data and forwards it to the trusted verification module 22. The trusted verification module 22 will perform a final verification of the data, including verifying the data's integrity, authenticity, and whether it meets the requirements for global model updates. The trusted verification module 22 will verify the local model update and contribution proof in the response packet according to preset standards, ensuring that it complies with all verification rules, and decide whether to integrate the data into the global model, further enhancing the security and reliability of data transmission.

[0062] The trusted verification module 22 is used to arbitrate the contribution of the local response packets returned from the subsystems of each participating party and generate a contribution arbitration result.

[0063] Furthermore, the trusted verification module 22 is also used to perform the following steps:

[0064] Extract contribution proofs from all local response packets and arrange them into a vector set; calculate the central tendency metric of the vector set and the distance of each vector to the central tendency; based on the distribution of the distances in historical iterations, dynamically calculate and set an adaptive threshold, and mark vectors whose distances exceed the adaptive threshold as candidate outliers; for the participants corresponding to the candidate outliers, analyze the consistency between their local model updates and the historical update directions of the global model parameters; if their update direction shows a high negative correlation or randomness with the mainstream direction, then their corresponding contribution proofs are determined to be unreliable, and their local model updates are marked as malicious updates or low-quality updates.

[0065] Specifically, when arbitrating the contribution of local response packets returned from the subsystems of each participating party, the trusted verification module 22 of this application first extracts contribution proofs from all local response packets. These contribution proofs reflect the contribution made by each participating party to the optimization of the global model. In order to effectively evaluate the contribution of all participating parties, the trusted verification module 22 arranges all extracted contribution proofs in order and forms a vector set. This vector set contains the contribution of each participating party, facilitating subsequent analysis and comparison.

[0066] Next, a central tendency measure for the vector set is calculated. This can be the mean vector of the vector set or other central tendency indicators. The central tendency measure reflects the average level or typical characteristics of the contribution proofs of all participants. Simultaneously, the distance of each vector to this central tendency is calculated, for example, using Euclidean distance or other suitable distance metrics. The distance of each vector represents the deviation of that participant's contribution proof from the overall contribution. If the distance of a participant's contribution proof exceeds a preset adaptive threshold, this indicates that the participant's contribution performance deviates significantly from that of other participants, potentially indicating an anomaly.

[0067] Then, the trust verification module 22 marks vectors whose distance exceeds an adaptive threshold as candidate outliers. The adaptive threshold is dynamically determined based on the statistical properties of the vector set, for example, it could be a multiple of the standard deviation or a threshold determined through cluster analysis. This step aims to identify vectors that differ significantly from the overall contribution proof, which may correspond to anomalous or untrustworthy contributions.

[0068] For the participants corresponding to the vectors marked as candidate outliers, the credibility verification module 22 further analyzes the consistency between their local model updates and the historical update directions of the global model parameters. Specifically, the credibility verification module 22 will check the relationship between the direction of the participant's local model updates in this round of training and the trend of global model updates in the past few rounds. The historical update direction of the global model can be calculated by summarizing the update directions of all participants in the past to form a mainstream update direction. This step is achieved by calculating the correlation between update directions, such as using Pearson correlation coefficient or cosine similarity.

[0069] If a participant's local model update direction shows a high negative correlation or randomness with the historical update direction of the global model, it indicates that the participant's contribution may not conform to the development trend of the global model, suggesting abnormal behavior. Based on this analysis, the credibility verification module 22 will determine that the participant's contribution proof is untrustworthy and mark its local model update as malicious or low-quality. This processing step effectively identifies participants attempting to disrupt the training process through inappropriate updates, ensuring the quality of global model updates.

[0070] Furthermore, the trusted verification module 22 is also used to perform exception handling steps:

[0071] The trusted verification module sends an emergency pause command to the global coordination module, interrupting the generation and distribution of the second synchronization package in the current iteration process; the global coordination module retrieves the most recently marked stable global model parameter version and uses this global model parameter version to overwrite the current global model parameter state in memory.

[0072] Optionally, after identifying an untrusted contribution proof or a malicious / low-quality local model update, the trusted verification module 22 needs to perform further anomaly handling steps to ensure the security and stability of the global model.

[0073] First, when the trusted verification module 22 detects anomaly in contribution proofs and determines through its anomaly detection mechanism that model updates from certain participants are malicious or low-quality updates, it issues an emergency pause command to the global coordination module 21. The purpose of this command is to interrupt the generation and distribution of the second synchronization package in the current iteration process. The second synchronization package typically contains updated global model parameters and new dynamic verification rules, ready to be distributed to all participants for the next round of training. If this step continues, the abnormal local model updates may affect the quality of the global model and could even cause the model to deviate from the expected optimization objective; therefore, pausing this process is a crucial measure to ensure model stability.

[0074] Upon receiving an emergency pause command, the global coordination module 21 immediately stops the current iteration process to prevent the second synchronization packet from continuing to be generated and sent. Simultaneously, the global coordination module 21 retrieves the most recently marked stable version of the global model parameters. This version is a global model version that has undergone multiple iterations, verified by the contributions of all parties, and has no anomalies; it can serve as a reliable foundation for the current system. The global coordination module 21 uses this stable version of the global model parameters to overwrite the currently used global model parameter state in memory, ensuring that in the event of an anomaly, the system can recover to a known stable state, thereby avoiding the generation of more errors during further training.

[0075] This process ensures that the model can quickly recover to a stable state when anomalies occur, avoiding the negative impact of abnormal model updates on the global model. Simultaneously, pausing the current iteration and reverting to a stable model version provides the global coordination module with time to further analyze and diagnose the problem, ensuring that subsequent iterations are not further disrupted by malicious or low-quality updates.

[0076] The security aggregation module 23 is used to perform weighted aggregation of the local model updates that have passed the arbitration based on the contribution arbitration result, generate a new generation of global model parameters, and generate and encode the dynamic verification rules for the next round of verification based on the contribution arbitration result of this round.

[0077] Furthermore, when the security aggregation module 23 performs weighted aggregation of the local model updates that have passed arbitration based on the contribution arbitration result, it is also used to perform the following steps:

[0078] The contribution arbitration results are iterated through to select local model updates marked as trustworthy. For each trustworthy local model update, its contribution proof value is input into a monotonically increasing weight mapping function to calculate the basic aggregation weight. Based on the trustworthy behavior records of the corresponding participants in historical multiple iterations, the basic aggregation weight is increased as a reward or decreased as a penalty to obtain the final aggregation weight. All local model updates that pass arbitration are linearly combined according to their corresponding final aggregation weights to obtain the next-generation global model parameters.

[0079] It should be understood that when the security aggregation module 23 of this application performs weighted aggregation of the local model updates that have passed the arbitration based on the contribution arbitration result, it will first perform screening and weighting processing on the local model updates of all participants.

[0080] Specifically, the security aggregation module 23 iterates through all contribution arbitration results and filters out local model updates marked as trustworthy. These updates have been verified by the trust verification module 22, meet the contribution criteria, and have not been marked as abnormal. Only these trustworthy local model updates participate in the subsequent weighted aggregation steps to ensure that the final global model is optimized based on reliable data.

[0081] For each selected trusted local model update, the secure aggregation module 23 inputs the key values ​​from its contribution proof into a pre-defined monotonically increasing weight mapping function. This function calculates a base aggregation weight based on the magnitude of the contribution proof. For example, a higher contribution proof indicates a greater contribution from the participant to the model in this training iteration, resulting in a correspondingly higher base aggregation weight. This base aggregation weight serves as an important reference value in subsequent weighted aggregation processes, initially reflecting the contribution level of each participant in this iteration. The mapping function is monotonically increasing, meaning that higher contributions result in larger mapped weights.

[0082] After calculating the base aggregation weights for each local model update, the secure aggregation module 23 further adjusts these weights based on the participants' credible behavior records across multiple historical iterations. For example, for each participant, its past behavior records are reviewed to see if the local model updates submitted by the participant have consistently remained credible in previous iterations, whether they have been marked as untrustworthy, and the frequency and severity of such untrustworthy occurrences. Based on these historical records, the secure aggregation module 23 adjusts the base aggregation weights for each participant. If a participant has consistently performed well in historical iterations, and its submitted local model updates are almost always credible, a positive adjustment factor is applied to the participant's base aggregation weights, thereby increasing its final aggregation weight. This positive adjustment factor can be a fixed value or a coefficient dynamically calculated based on the number of historically credible updates. Its purpose is to reward participants who consistently contribute high-quality updates over a long period, giving them greater influence in the generation of global model parameters. Conversely, if a participant's historical record is flawed, such as having submitted unreliable updates or repeatedly exhibiting updates whose direction is highly negatively correlated with the mainstream direction, a negative adjustment factor is applied to that participant's base aggregation weight, thereby reducing its final aggregation weight. This negative adjustment factor can also be a fixed value or a dynamically calculated coefficient, with the aim of penalizing participants with a history of misconduct and reducing their potential negative impact on the global model parameters.

[0083] After the above two steps, the secure aggregation module 23 obtains the final aggregation weights for each trusted local model update. Then, the crucial weighted aggregation stage begins. In this stage, the secure aggregation module 23 linearly combines all arbitrated local model updates according to their corresponding final aggregation weights. Specifically, first, the parameters in each local model update, such as model weights and biases, are multiplied by their corresponding final aggregation weights to obtain weighted parameter values. Then, for each parameter, the weighted parameter values ​​of all participants are summed to obtain the total for that parameter. Finally, to ensure the stability and consistency of the next-generation global model parameters, the sum of each parameter is divided by the sum of the final aggregation weights of all participants for normalization. This yields the next-generation global model parameters. This weighted aggregation method fully considers the contribution of each participant in this iteration and their historical behavior, ensuring that the final generated global model parameters better reflect the true contributions of each participant while avoiding potential harm to the global model from malicious behavior.

[0084] Furthermore, when the security aggregation module 23 generates and encodes the dynamic verification rules for the next round of verification based on the contribution arbitration results of this round, it is also used to perform the following steps:

[0085] Analyze the cases marked as malicious or low-quality updates in the contribution arbitration results, and extract the common technical features they used when successfully passing the previous round of dynamic verification rules; generate corresponding reinforcement constraint strategies at the rule logic layer for the common technical features; encode the reinforcement constraint strategies into a rule instruction set, and update the corresponding rule segments in the dynamic verification rules to form the updated dynamic verification rules.

[0086] Specifically, after generating the parameters of the new generation global model, the security aggregation module 23 also undertakes an important task: adaptively updating the dynamic verification rules based on the contribution arbitration results of this round. This process is based on the performance of each participant in this iteration and their contribution to the global model. For example, if some participants are found to frequently submit untrusted updates, or if certain types of anomalous updates occur frequently in this iteration, the security aggregation module 23 will adjust the dynamic verification rules accordingly, raising the detection threshold for these situations or adding additional verification steps. Conversely, if most participants perform very well in this iteration, the security aggregation module 23 may appropriately relax some verification conditions to improve the system's operating efficiency.

[0087] Specifically, the trusted verification module 22 first filters out local model updates marked as malicious or low-quality updates from the contribution arbitration results. These updates fail verification because their contribution proofs may be fake or unexpected. Then, the security aggregation module 23 further analyzes the common characteristics of these updates, which may involve the range of model parameters, data interaction patterns, and the structure of contribution proofs. For example, malicious updates may focus on minor adjustments to certain model parameters or use non-standard data interaction methods to attempt to circumvent the verification rules.

[0088] If the analysis reveals that some malicious updates exploit the lenient boundaries of the model parameter range, the security aggregation module 23 will generate corresponding enhanced constraint strategies at the rule logic layer. These strategies may include tightening numerical boundaries and increasing verification of boundary values. For example, if the previous verification rules allowed model parameters to vary within a certain range, and a malicious update exploited this lenient range, the new rules will narrow this range and increase strict verification of boundary values ​​to ensure that all parameters remain within a reasonable and safe range.

[0089] If common technical features involve data interaction patterns, the security aggregation module 23 will add additional interaction challenges and response verification steps to the verification process. This means that in future verification processes, participants will need to prove the legitimacy of their data interactions through additional challenges. For example, randomly generated verification challenges can be added, requiring participants to provide correct responses within a specified time, thereby increasing the difficulty of malicious behavior.

[0090] If common technical features involve contribution proof structures, the security aggregation module 23 will require the proof to include more auditable evidence of intermediate computations. The purpose of this step is to increase the transparency and traceability of contribution proofs. For example, it requires participants to document key steps and intermediate results during the training process in detail within the contribution proof, enabling thorough auditing in subsequent verification.

[0091] After generating these enhanced constraint policies, the security aggregation module 23 encodes them into a set of rule instructions and updates the corresponding rule segments in the dynamic verification rules. This process ensures that the dynamic verification rules can adapt to current security requirements, promptly patch vulnerabilities, and prevent malicious and low-quality updates from affecting the training and optimization of the global model. The updated rules will be applied to subsequent iterations, forming a more rigorous and effective verification mechanism to guarantee the security and fairness of the system.

[0092] The global coordination module 21 is also used to encapsulate the new generation global model parameters and the re-encoded dynamic verification rules into a second synchronization package to initiate the next round of iteration.

[0093] Optionally, after generating the next-generation global model parameters and updating the dynamic verification rules, the global coordination module 21 of this application is also responsible for encapsulating these updates into a second synchronization package, thereby preparing for the next round of joint learning iterations. This process ensures that all participants use unified and optimized model parameters and verification rules in the new iteration, maintaining the synchronicity and security of the joint learning process.

[0094] Specifically, the global coordination module 21 first ensures that the next-generation global model parameters have undergone rigorous aggregation calculations, integrating model updates contributed by all participants, and that all updates meet the standards for trusted verification and secure aggregation. These newly generated model parameters reflect the optimization of the global model through multi-party collaboration, ensuring that the next iteration can proceed on a unified and improved basis.

[0095] Simultaneously, the dynamic verification rules updated based on the results of this round of contribution arbitration will be encapsulated. These rules are adaptively adjusted according to the results of this round of contribution arbitration, aiming to better detect and prevent malicious or low-quality updates. The updated dynamic verification rules include enhanced constraint strategies for common technical features, such as tightening numerical boundaries, adding boundary value checks, adding additional interactive challenges and response verification steps, and requiring contribution proofs to include more auditable intermediate computational evidence. These rules will serve as the verification basis for participants submitting local model updates in the next iteration.

[0096] Next, the global coordination module 21 encapsulates the next-generation global model parameters and the updated dynamic verification rules into a unified data packet, namely the second synchronization packet. This synchronization packet contains not only the optimized global model parameters but also the adaptively updated dynamic verification rules. After encapsulation, the global coordination module 21 unidirectionally transfers the second synchronization packet to each participating party's subsystem 30 via the security isolation gateway 10. Once the second synchronization packet is sent to each participating party's subsystem, it will trigger the start of the next iteration. In the next round, the participants will train based on this next-generation global model and follow the updated dynamic verification rules for data verification and model updates, ensuring the security, fairness, and efficiency of the entire training process.

[0097] In summary, the embodiments of this application have at least the following technical effects:

[0098] This application effectively protects data privacy by employing a unidirectional data transmission mechanism through a secure isolation gateway to ensure that the privacy data of each participant is not leaked or reversed during multi-party collaborative computation. Through a trusted execution module and dynamic verification rules, it ensures that each participant's local model updates are trained without disclosing sensitive information, improving the efficiency of distributed computing and collaborative learning. By adopting contribution arbitration and weighted aggregation methods, it effectively identifies and prevents malicious updates, ensuring that global model updates are based on trusted data and valid contributions. The application automatically updates dynamic verification rules based on contribution arbitration results, enhancing the system's adaptability to different participant behaviors and ensuring its stability and security in various environments. Through simplified unidirectional data flow and a trusted execution environment, it reduces protocol complexity and computational burden in privacy-preserving computation, improving system scalability and computational efficiency.

[0099] It achieves the technical effect of simplifying privacy protection, effectively preventing malicious updates, and improving the security and efficiency of cross-domain information processing by using a secure isolation gateway.

[0100] It should be noted that the order of the embodiments described above is merely for descriptive purposes and does not represent the superiority or inferiority of the embodiments. Furthermore, the above description focuses on specific embodiments of this specification. Additionally, the processes depicted in the accompanying drawings do not necessarily require a specific or sequential order to achieve the desired results. In some implementations, multitasking and parallel processing are possible or may be advantageous.

[0101] The above description is only a preferred embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

[0102] This specification and accompanying drawings are merely illustrative examples of this application and are intended to cover any and all modifications, variations, combinations, or equivalents within the scope of this application. Clearly, those skilled in the art can make various alterations and modifications to this application without departing from its scope. Therefore, if such modifications and variations fall within the scope of this application and its equivalents, this application intends to include such modifications and variations.

Claims

1. An information data processing system based on a security isolation gateway, characterized in that, The system includes: A security isolation gateway comprises a global side subsystem and N participating side subsystems, where N is a positive integer. The security isolation gateway is connected between the global side subsystem and each participating side subsystem. Its hardware architecture is configured to support a unidirectional data transfer channel for sequential unidirectional transmission between the global side subsystem and the participating side subsystems. The global side subsystem includes a global coordination module, a trusted verification module, and a security aggregation module. Each participating side subsystem includes a trusted execution module. The global coordination module is used to generate a first synchronization package containing global model parameters and dynamic verification rules, and to transfer it unidirectionally to the subsystems of each participating party in a first unidirectional mode through the security isolation gateway. The trusted execution module in each of the participating party subsystems is used to verify the first synchronization packet based on dynamic verification rules after receiving it. After the verification is successful, the module uses local privacy data to train the global model parameters, generate a local model update and contribution proof, and then uses the security isolation gateway to unidirectionally transfer the local response packet containing the local model update and contribution proof back to the global subsystem in a second one-way mode. The security isolation gateway is configured to start the second one-way mode only after the data transmission in the first one-way mode is completed. The trusted verification module is used to arbitrate the contribution of local response packets returned from the subsystems of each participating party and generate a contribution arbitration result. The security aggregation module is used to perform weighted aggregation of the local model updates that have passed the arbitration based on the contribution arbitration result, generate a new generation of global model parameters, and generate and encode the dynamic verification rules for the next round of verification based on the contribution arbitration result of this round. The global coordination module is also used to encapsulate the next-generation global model parameters and the re-encoded dynamic verification rules into a second synchronization package to initiate the next iteration. When the security aggregation module performs weighted aggregation of the local model updates that have passed arbitration based on the contribution arbitration result, it is also used to: Iterate through the contribution arbitration results and filter out the local model updates that are marked as credible; For each reliable local model update, its contribution proof value is input into a monotonically increasing weight mapping function to calculate the basic aggregate weights; Based on the credible behavior records of the corresponding participants in multiple historical iterations, the basic aggregation weight is increased in a rewarding manner or decreased in a punitive manner to obtain the final aggregation weight; Update all local models that pass arbitration, and linearly combine them according to their corresponding final aggregation weights to obtain the parameters of the next-generation global model; When the security aggregation module generates and encodes the dynamic verification rules for the next round of verification based on the contribution arbitration results of this round, it is also used to: Analyze the cases marked as malicious updates or low-quality updates in the contribution arbitration results, and extract the common technical features they used when they successfully passed the previous round of dynamic verification rules; Based on the aforementioned common technical features, corresponding reinforcement constraint strategies are generated at the rule logic layer; The enhanced constraint strategy is encoded into a set of rule instructions, and the corresponding rule segments in the dynamic verification rule are updated to form the updated dynamic verification rule.

2. The information data processing system based on a security isolation gateway as described in claim 1, characterized in that, The trusted execution module is also used for: The integrity and origin of the first synchronization packet are verified according to the dynamic verification rules; After successful verification, the global model parameters in the first synchronization package are trained using local privacy data within a trusted execution environment to generate the local model update and the contribution proof.

3. The information data processing system based on a security isolation gateway as described in claim 2, characterized in that, When the trusted execution module verifies the integrity and origin of the first synchronization packet according to the dynamic verification rules, it is also used to: Extract the pre-generated data digest code from the dynamic verification rule, and execute the same digest generation function on the global model parameters in the first synchronization packet to obtain the real-time digest code; The real-time digest code and the data digest code are compared bit by bit. If they are completely consistent, the integrity verification is deemed to have passed. As a parallel and independent verification step, the associated transmission metadata is parsed from the first synchronization packet, and it is verified whether the transmission metadata contains a unique channel identifier and digital seal embedded by the security isolation gateway during the transfer. If the channel identifier matches the preset identifier in the dynamic verification rules, and the digital seal passes the asymmetric cryptography verification, then the source verification is deemed successful.

4. The information data processing system based on a security isolation gateway as described in claim 3, characterized in that, The trusted execution module trains the global model parameters in the first synchronization package using local privacy data within the trusted execution environment. When generating local model updates, it is also used for: Within a closed computing environment, the local privacy dataset is divided into multiple batches; For each batch of data, the computation graph defined by the global model parameters is input sequentially, and forward propagation is performed to obtain the prediction output; The loss value is calculated based on the predicted output and the true label. Perform backpropagation to calculate the gradient change of each parameter in the global model parameters relative to the loss value; After all batches of data have been processed, the gradient changes of all batches are summarized, and the overall adjustment of the global model parameters is calculated and used as the local model update.

5. The information data processing system based on a security isolation gateway as described in claim 4, characterized in that, The trusted execution module, when generating contribution proof, is also used for: Record the loss values ​​during the training process and calculate the relative rate of decrease in loss from the initial value to the final value; Perform feature analysis on the local privacy dataset and calculate the difference measure between its data distribution and the preset general reference distribution; Statistical analysis is performed on the overall adjustment amount to calculate its numerical norm; The relative decrease rate, the difference measure, and the numerical norm are input into a preset contribution quantification function to calculate and generate the contribution proof.

6. The information data processing system based on a security isolation gateway as described in claim 1, characterized in that, When the trusted execution module executes the unidirectional transfer of the local response packet containing the local model update and contribution proof back to the global side subsystem via the security isolation gateway in the second unidirectional mode, it is also used to: After receiving the local response packet, the sending agent of the security isolation gateway performs a content compliance check on the data in the packet according to the content filtering strategy defined for the model update data structure. Once the content compliance check passes, the data within the package is converted to an intermediate format, and the physical isolation switch is triggered to cache the data in the isolated storage area. After the physical isolation switch is disconnected, the receiving agent of the security isolation gateway reads data from the isolation storage area and forwards it to the trusted verification module.

7. The information data processing system based on a security isolation gateway as described in claim 1, characterized in that, The trusted verification module is also used for: Extract the contribution proofs from all local response packets and arrange them into a vector set; Calculate the central tendency metric of the vector set, and the distance of each vector to the central tendency; Based on the distribution of distances in historical iterations, an adaptive threshold is dynamically calculated and set, and vectors whose distances exceed the adaptive threshold are marked as candidate outliers. For the participants corresponding to the candidate outliers, analyze the consistency between their local model updates and the historical update direction of the global model parameters; If its update direction shows a high negative correlation or randomness with the mainstream direction, its corresponding contribution proof is judged as unreliable, and its local model update is marked as a malicious update or a low-quality update.

8. The information data processing system based on a security isolation gateway as described in claim 7, characterized in that, When the contribution arbitration identifies a malicious update exceeding a preset threshold, the trusted verification module is also used to perform anomaly handling steps: The trusted verification module sends an emergency pause command to the global coordination module, interrupting the generation and distribution of the second synchronization package in the current iteration process; The global coordination module retrieves the most recently marked stable version of the global model parameters and uses this version to overwrite the current global model parameter state in memory.

Images