Joint learning with partitioning and dynamic shuffling model updates

Abstract

This invention relates to federated learning with partitioned and dynamically shuffled model updates. The federated learning technique utilizes a multi-layered defense strategy to reduce information leakage. Instead of centralized aggregation of model updates, the aggregation function is distributed across multiple independent and functionally equivalent execution entities, each running within its own TEE. The TEE enables confidential and remotely provable federated aggregation. Each aggregator entity runs within an encrypted virtual machine supporting runtime memory encryption. Each party remotely authenticates its TEE before participating in training. Using multiple distributed aggregators, parties can partition their respective model updates at the granularity of model parameters and map individual weights to specific aggregator entities. Parties can also dynamically shuffle fragmented model updates at each training iteration to further obfuscate the information assigned to each aggregator execution entity. This architecture prevents the aggregator from becoming a single point of failure and protects the model even if all aggregators are compromised.

Description

Technical Field

[0001] This invention essentially relates to techniques for distributed machine learning. Background Technology

[0002] Federation learning (FL) provides a collaborative training mechanism that allows multiple parties to build machine learning (ML) models together. Unlike merging all training data in a central training server (or data center), federated learning allows parties to retain private data within their trusted and protected domains / infrastructure. Each party trains its local model and only periodically uploads model updates or gradients to a central aggregation server. This aggregator merges the model updates and broadcasts the aggregated model back to the parties for model synchronization. The setup of federated learning training presents unique advantages for preserving the privacy of training data. This is particularly attractive for training parties that do not trust or compete with each other, and for holders of sensitive data (e.g., health and financial data) where laws or regulations prohibit data sharing.

[0003] There's a misconception in federated learning that model updates exchanged in federated learning (FL) communication contain less information than the original training data. This leads to the conclusion that sharing model updates is "privacy-preserving." However, model updates are derived directly from the local training data. While it may not be explicitly discernible, information from the training data is still hidden within the representation of the model update. Recent research challenges the privacy promise of federated learning. Specifically, this research shows that even with an honest but curious central aggregation server, an adversary could fully exploit model updates to infer private properties or reconstruct the training data.

[0004] Existing techniques for addressing these issues involve differential privacy aggregation through adding statistical noise to model updates and using cryptographic primitives such as Secure Multi-Party Computation (SMC) protocols or homomorphic encryption (HE). Both techniques have drawbacks. The former typically significantly reduces the accuracy of the trained model and requires careful hyperparameter tuning, while the latter is computationally expensive. Furthermore, because the parties do not trust each other, the central aggregator often runs on untrusted third-party (cloud) computing infrastructure and can become a single point of failure during an attack.

[0005] Therefore, there remains a need to provide an enhanced joint learning framework to address this threat model. Summary of the Invention

[0006] According to this disclosure, a joint learning system and method for training neural networks to prevent privacy breaches and data reconstruction attacks are described. The method in this paper provides enhanced protection against information breaches by leveraging a multi-layered defense strategy, which includes several aspects: trusted aggregation, distributed aggregation with model segmentation, and dynamic permutation.

[0007] As used herein, trusted aggregation refers to the concept of using a Trusted Execution Environment (TEE) that provides runtime memory encryption and remote authentication to facilitate isolated and confidential execution on untrusted servers. Decentralized aggregation refers to the concept of dividing a central aggregator into multiple independent and functionally equivalent execution entities, each of which subsequently runs within an encrypted virtual machine. With multiple decentralized aggregators, parties have the freedom to decompose model updates at the granularity of model parameters and to map each individual weight to a specific aggregator. Therefore, preferably, each aggregator has only a partial view of the model update and is not concerned with the model architecture. By dispersing individual aggregators with partitioned model updates, this method prevents aggregators from becoming single points of failure under security attacks (e.g., security attacks targeting certain TEEs). Furthermore, users can further deploy multiple aggregators across physical servers in different geographical locations and potentially have diverse TEEs on different microprocessors. Even if a subset of aggregators is compromised, an adversary cannot piece together the entire model update information.

[0008] In one exemplary implementation, each aggregator execution entity runs within a cryptographic virtual machine (EVM) with runtime memory encryption. Before participating in training, each party in the joint learning remotely authenticates the hardware as real and establishes an end-to-end secure channel for exchanging model updates.

[0009] According to the additional aspect, as described above, the additional defense strategy is referred to herein as dynamic permutation. Dynamic permutation leverages the concept that the arithmetic operations across model updates of joint learning fusion algorithms (e.g., joint stochastic gradient descent (FedSGD) and joint averaging (FedAvg)) are bijective. Therefore, splitting and (internal) shuffling of model updates does not affect the fusion result. According to this aspect of the disclosure, parties are provided with the ability to dynamically shuffle fragments of model updates at each training iteration to further obfuscate the information assigned to each aggregator execution entity. This strategy guarantees that even if all dispersed aggregators are destroyed, the adversary cannot decrypt the correct ordering of model updates used to reconstruct the training data. Dynamic permutation is enabled when the transformations on the model update side are deterministic, reversible, and identical between the parties.

[0010] The foregoing outlines some of the more relevant characteristics of this topic. These characteristics should be interpreted as illustrative only. Many other beneficial results can be obtained by applying the disclosed topics in different ways or by modifying the topics to be described. Attached Figure Description

[0011] To gain a more complete understanding of the subject matter and its advantages, please now refer to the following description in conjunction with the accompanying drawings, in which:

[0012] Figure 1 An exemplary block diagram of a distributed data processing environment that can implement exemplary aspects of the illustrative embodiments is shown;

[0013] Figure 2 An exemplary block diagram of a data processing system that can implement exemplary aspects of illustrative embodiments is shown;

[0014] Figure 3 A cloud computing environment for a fusion server that can implement a secure distributed machine learning framework according to this disclosure is shown.

[0015] Figure 4 illustrates a distributed learning framework involving an aggregation server and a set of data owners / learning agents;

[0016] Figure 5 This illustrates the first security technique referred to in this paper as trusted aggregation;

[0017] Figure 6 The system architecture for implementing trusted and decentralized joint learning as disclosed herein is shown; and

[0018] Figure 7 The paper illustrates a representative implementation of the model partitioning and dynamic permutation scheme. Detailed Implementation

[0019] Now refer to the attached diagram and see for details. Figure 1-2 Exemplary diagrams are provided illustrating a data processing environment that can implement the illustrative embodiments of this disclosure. It should be understood that... Figure 1-2 This is merely illustrative and is not intended to assert or imply any limitation on the environment in which the aspects or embodiments of the disclosed subject matter are implemented. Many modifications may be made to the depicted environment without departing from the spirit and scope of the invention.

[0020] Now refer to the attached diagram, Figure 1 A graphical representation of an exemplary distributed data processing system in which aspects of the illustrative embodiments can be implemented is depicted. The distributed data processing system 100 may include a computer network in which aspects of the illustrative embodiments can be implemented. The distributed data processing system 100 includes at least one network 102, which is a medium for providing communication links between different devices and computers connected together within the distributed data processing system 100. The network 102 may include connections such as wired, wireless communication links, or fiber optic cables.

[0021] In the depicted example, servers 104 and 106 are connected to network 102 along with storage unit 108. Clients 110, 112, and 114 are also connected to network 102. These clients 110, 112, and 114 can be, for example, personal computers, network computers, etc. In the depicted example, server 104 provides data such as boot files, operating system images, and applications to clients 110, 112, and 114. In the depicted example, clients 110, 112, and 114 are clients of server 104. The distributed data processing system 100 may include additional servers, clients, and other devices not shown.

[0022] In the depicted example, the distributed data processing system 100 is an internet with network 102, which represents a global collection of networks and gateways communicating with each other using the Transmission Control Protocol / Internet Protocol (TCP / IP) protocol suite. The core of the internet is the backbone of high-speed data communication lines between master nodes or host computers, composed of thousands of commercial, government, educational, and other computer systems routing data and messages. Of course, the distributed data processing system 100 can also be implemented as including multiple different types of networks, such as, for example, intranets, local area networks (LANs), wide area networks (WANs), etc. As described above, Figure 1 The intent is to be illustrative, not to be construed as an architectural limitation on different embodiments of the disclosed subject matter, and therefore, in Figure 1 The specific elements shown should not be considered as limitations on the environment in which the illustrative embodiments of the invention may be implemented.

[0023] Now for reference Figure 2 This diagram illustrates a block diagram of an exemplary data processing system that can implement various aspects of the illustrative embodiments. The data processing system 200 is a computer (such as...) Figure 1 Examples of client 110 in the present disclosure may be provided, in which computer-usable code or instructions for implementing the processing of illustrative embodiments of the present disclosure may be located.

[0024] Now for reference Figure 2 A block diagram of a data processing system that can implement illustrative embodiments is shown. The data processing system 200 is a computer (such as...) Figure 1 Examples of server 104 or client 110 in the illustrative embodiment may include computer-usable program code or instructions for implementing the process. In this illustrative example, the data processing system 200 includes a communication structure 202 that provides communication between processor unit 204, memory 206, persistent memory 208, communication unit 210, input / output (I / O) unit 212, and display 214.

[0025] Processor unit 204 is used to execute instructions for software that can be loaded into memory 206. Processor unit 204 may be a collection of one or more processors, or it may be a multiprocessor core, depending on the specific implementation. Furthermore, processor unit 204 may be implemented using one or more heterogeneous processor systems, in which the main processor and secondary processor reside on a single chip. As another illustrative example, processor unit 204 may be a symmetric multiprocessor (SMP) system containing multiple processors of the same type.

[0026] Memory 206 and persistent memory 208 are examples of storage devices. A storage device is any hardware capable of temporarily and / or permanently storing information. In these examples, memory 206 may be, for example, random access memory or any other suitable volatile or non-volatile storage device. Persistent memory 208 may take various forms depending on the specific implementation. For example, persistent memory 208 may include one or more components or devices. For example, persistent memory 208 may be a hard disk drive, flash memory, rewritable optical disk, rewritable magnetic tape, or a combination of the above. The medium used by persistent memory 208 may also be removable. For example, a removable hard disk drive may be used for persistent memory 208.

[0027] In these examples, communication unit 210 provides communication with other data processing systems or devices. In these examples, communication unit 210 is a network interface card. Communication unit 210 can provide communication using either or both physical and wireless communication links.

[0028] Input / output unit 212 allows data input and output to other devices that can be connected to data processing system 200. For example, input / output unit 212 can provide connectivity for user input via keyboard and mouse. Furthermore, input / output unit 212 can send output to a printer. Display 214 provides a mechanism for displaying information to the user.

[0029] Instructions for operating systems and applications or programs reside on permanent memory 208. These instructions may be loaded into memory 206 for execution by processor unit 204. Processor unit 204 may use computer-implemented instructions to perform processes of different embodiments, which may reside in memory (e.g., memory 206). These instructions are referred to as program code, computer-usable program code, or computer-readable program code that can be read and executed by a processor in processor unit 204. The program code in different embodiments may be implemented on different physical or tangible computer-readable media, such as memory 206 or permanent memory 208.

[0030] Program code 216 is functionally located on a selectively removable computer-readable medium 218 and can be loaded into or transferred to the data processing system 200 for execution by the processor unit 204. In these examples, program code 216 and computer-readable medium 218 form a computer program product 220. In one example, computer-readable medium 218 may be in a tangible form, such as an optical disc or disk inserted into or placed in a drive or other device that is part of persistent storage 208 for transfer to a storage device, such as a hard disk drive that is part of persistent storage 208. In a tangible form, computer-readable medium 218 may also take the form of persistent storage, such as a hard disk drive, thumb drive, or flash memory connected to the data processing system 200. The tangible form of computer-readable medium 218 is also referred to as a computer-recordable storage medium. In some instances, computer-readable medium 218 may not be removable.

[0031] Alternatively, program code 216 can be transmitted from computer-readable medium 218 to data processing system 200 via a communication link to communication unit 210 and / or via a connection to input / output unit 212. In illustrative examples, the communication link and / or connection can be physical or wireless. The computer-readable medium can also take the form of intangible media, such as a communication link containing program code or wireless transmission. The different components shown for data processing system 200 do not imply an architectural limitation on the ways in which different embodiments can be implemented. Different illustrative embodiments can be implemented in data processing systems that include components other than or in lieu of those shown for data processing system 200. Figure 2 Other components shown may differ from the illustrative example shown. As an example, the storage device in data processing system 200 is any hardware device capable of storing data. Memory 206, persistent memory 208, and computer-readable medium 218 are examples of tangible storage devices.

[0032] In another example, a bus system can be used to implement communication structure 202 and may include one or more buses, such as a system bus or an input / output bus. Of course, any suitable type of architecture that provides data transfer between different components or devices attached to the bus system can be used to implement the bus system. Furthermore, the communication unit may include one or more devices for sending and receiving data, such as a modem or network adapter. Further, the memory may be, for example, memory 206 or a cache such as that found in the interface and memory controller hub that may be present in communication structure 202.

[0033] The computer program code for performing the operations of this invention can be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java. TM Languages ​​such as Smalltalk and C++ are also included, as well as conventional procedural programming languages ​​such as C or similar languages. Program code can execute entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter case, the remote computer can be connected to the user's computer via any type of network (including a local area network (LAN) or a wide area network (WAN)), or can be connected to an external computer (e.g., via the internet using an internet service provider).

[0034] Those skilled in the art will understand that Figure 1-2 The hardware within can vary depending on the implementation. Besides or replacing... Figure 1-2 The hardware described herein can be replaced with other internal hardware or peripheral devices, such as flash memory, equivalent non-volatile memory, or optical disc drives. Furthermore, the processes of the illustrative embodiments, without departing from the spirit and scope of the disclosed subject matter, can be applied to multiprocessor data processing systems that are not the aforementioned SMP systems.

[0035] As will be seen, the techniques described in this article can be applied to, for example... Figure 1 The example illustrates collaborative operation within a standard client-server paradigm, where client machines communicate with an internet-accessible, web-based portal running on one or more machine groups. End-users operate internet-connected devices (e.g., desktop computers, laptops, internet-enabled mobile devices, etc.) capable of accessing and interacting with the portal. Typically, each client or server machine is such as... Figure 2 The diagram illustrates a data processing system comprising hardware and software, and these entities communicate with each other via networks such as the Internet, intranets, extranets, private networks, or any other communication medium or link. A data processing system typically includes one or more processors, an operating system, one or more applications, and one or more utilities. Applications on the data processing system provide native support for Web services, including but not limited to support for HTTP, SOAP, XML, WSDL, UDDI, and WSFL. Information on SOAP, WSDL, UDDI, and WSFL is available from the World Wide Web Consortium (W3C), which is responsible for developing and maintaining these standards; further information on HTTP and XML is available from the Internet Engineering Task Force (IETF). Familiarity with these standards is assumed.

[0036] Applications on data processing systems can also use native support for non-standard protocols, or be developed as proprietary protocols to work on TCP / IP networks.

[0037] Cloud computing model

[0038] As described above, the distributed machine learning techniques of this disclosure preferably utilize computing elements located in a cloud computing environment. Therefore, the following additional background information on cloud computing is provided.

[0039] Cloud computing is a service delivery model designed to enable convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, network bandwidth, servers, processing power, storage, applications, virtual machines, and services) that can be rapidly provisioned and released with minimal management effort or interaction with the service provider. This cloud model can include at least five features, at least three service models, and at least four deployment models, all of which are described and defined more specifically in Peter Mell and Tim Grance's "The NIST Definition of Cloud Computing" published in September 2011.

[0040] Specifically, the following are typical characteristics:

[0041] On-demand self-service: Cloud consumers can unilaterally and automatically provide computing power, such as server time and network storage, as needed, without requiring human interaction with the service provider.

[0042] Extensive network access: Capabilities are available through networks and access is facilitated by standard mechanisms that promote the use of heterogeneous thin client platforms or thick client platforms (e.g., mobile phones, laptops, and PDAs).

[0043] Resource pooling: A provider's computing resources are pooled to serve multiple consumers using a multi-tenant model, where different physical and virtual resources are dynamically assigned and reassigned as needed. There is a sense of location independence because consumers typically do not have control or knowledge of the exact location of the resources provided, but may be able to specify the location at a higher level of abstraction (e.g., country, province, or data center).

[0044] Rapid flexibility: The ability to provide capacity quickly and flexibly, automatically scaling down and up rapidly in some situations to scale up rapidly. For consumers, the available supply capacity often appears unlimited and can be purchased in any quantity at any time.

[0045] Measuring services: Cloud systems automatically control and optimize resource usage by leveraging metering capabilities at a level of abstraction appropriate to the service type (e.g., storage, processing, bandwidth, and active user accounts). Resource usage can be monitored, controlled, and reported, providing transparency to both service providers and consumers.

[0046] The service model is typically as follows:

[0047] Software as a Service (SaaS): This provides consumers with the ability to use the provider's applications running on cloud infrastructure. Applications can be accessed from different client devices via thin client interfaces such as web browsers (e.g., web-based email). Consumers do not manage or control the underlying cloud infrastructure, including the network, servers, operating system, storage, or even individual application capabilities, with possible exceptions such as limited user-specific application configuration settings.

[0048] Platform as a Service (PaaS): This provides consumers with the ability to deploy applications created or acquired by the consumer using programming languages ​​and tools supported by the provider onto cloud infrastructure. Consumers do not manage or control the underlying cloud infrastructure, including networks, servers, operating systems, or storage, but they have control over the deployed applications and the configuration of any application hosting environment.

[0049] Infrastructure as a Service (IaaS): The capabilities offered to consumers are processing, storage, networking, and other basic computing resources that enable consumers to deploy and run arbitrary software, which may include operating systems and applications. Consumers do not manage or control the underlying cloud infrastructure, but rather have control over the operating system, storage, deployed applications, and potentially limited control over selected networking components (e.g., host firewalls).

[0050] The deployment model is typically as follows:

[0051] Private cloud: A cloud infrastructure that operates solely for an organization. It can be managed by the organization or a third party and can exist on-site or off-site.

[0052] Community cloud: A cloud infrastructure shared by several organizations and supporting a specific community with shared concerns (e.g., tasks, security requirements, policies, and compliance considerations). It can be managed by an organization or a third party and can exist on-site or off-site.

[0053] Public cloud: Makes cloud infrastructure available to the public or large industry groups and is owned by an organization that sells cloud services.

[0054] Hybrid cloud: A cloud infrastructure is a combination of two or more clouds (private, community, or public) that remain a single entity but are bound together by standardized or proprietary technologies that enable data and applications to be ported (e.g., cloud bursting for load balancing between clouds).

[0055] Cloud computing environments are service-oriented, focusing on statelessness, loose coupling, modularity, and semantic interoperability. The core of cloud computing is its infrastructure, which includes a network of interconnected nodes. Representative cloud computing nodes are shown above. Figure 2 As shown. Specifically, within a cloud computing node, there exists a computer system / server that can operate alongside many other general-purpose or special-purpose computing system environments or configurations. Examples of well-known computing systems, environments, and / or configurations suitable for use with the computer system / server include, but are not limited to, personal computer systems, server computer systems, thin clients, thick clients, handheld or laptop devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputer systems, mainframe computers, and distributed cloud computing environments that include any of the above systems or devices. The computer system / server can be described in the general context of computer system executable instructions, such as program modules, executed by the computer system. Generally, program modules may include routines, programs, objects, components, logic, data structures, etc., that perform specific tasks or implement specific abstract data types. The computer system / server can be practiced in a distributed cloud computing environment where tasks are performed by remote processing devices linked via a communication network. In a distributed cloud computing environment, program modules can reside in local and remote computer system storage media, including memory storage devices.

[0056] In a typical cloud computing environment, and as Figure 3 As shown, a set of functional abstraction layers is provided. These include hardware and software layers, virtualization layers, management layers, and workload layers.

[0057] The hardware and software layer 300 includes hardware and software components. Examples of hardware components include mainframes, which in one example are... System; a server based on a RISC (Reduced Instruction Set Computer) architecture, in one example being an IBM... System; IBM System; IBM Systems; storage devices; networks and network components. Examples of software components include network application server software, one example being IBM. Application server software; and database software, in one example, IBM. Database software. (IBM, zSeries, pSeries, xSeries, BladeCenter, WebSphere, and DB2 are trademarks of International Business Machines Corporation registered in many jurisdictions worldwide.)

[0058] The virtualization layer 302 provides an abstraction layer from which the following examples of virtual entities can be provided: virtual servers; virtual storage; virtual networks, including virtual private networks; virtual applications and operating systems; and virtual clients.

[0059] Management section 304 provides various management functions. For example, resource provisioning provides dynamic procurement of computing resources and other resources used to perform tasks within the cloud computing environment. Metering and pricing provides cost tracking as resources are utilized within the cloud computing environment and bills or invoices for the consumption of these resources. In one example, these resources may include application software licenses. Security provides authentication for cloud consumers and tasks, as well as protection for data and other resources. The user portal provides consumers and system administrators with access to the cloud computing environment. Service level management provides the allocation and management of cloud computing resources to ensure that required service levels are met. Service level agreements (SLAs) plan and fulfill the pre-arrangement and procurement of cloud computing resources, anticipating future requirements for those resources.

[0060] Workload layer 306 provides the functionality that can be utilized in a cloud computing environment. Examples of workloads and functionalities that may be provided from this layer include: mapping and navigation; software development and lifecycle management; virtual classroom education delivery; data analytics and processing; transaction processing; enterprise-specific functionalities in a private cloud; and distributed machine learning 308 in accordance with this disclosure.

[0061] Therefore, a representative cloud computing environment has a set of high-level functional components, including a front-end identity manager, a Business Support Service (BSS) functional component, an Operations Support Service (OSS) functional component, and a compute cloud component. The identity manager is responsible for interacting with requesting clients to provide identity management, and this component can be implemented using one or more known systems, such as the Tivoli Federation Identity Manager (TFIM) available from IBM in Armonk, New York. Where appropriate, TFIM can be used to provide Federation Single Sign-On (F-SSO) to other cloud components. The Business Support Service component provides certain management functions, such as billing support. The Operations Support Service component is used to provide provisioning and management of other cloud components, such as virtual machine (VM) instances. A VM is an operating system or application environment installed on software but mimicking a hardware machine. A cloud component represents a primary compute resource, typically multiple VM instances used to execute a target application accessible via the cloud. One or more databases are used to store directories, logs, and other working data. All these components (including the front-end identity manager) reside “within” the cloud, but this is not mandatory. In alternative embodiments, the identity manager can operate outside the cloud. Service providers can also operate outside the cloud.

[0062] Some clouds are based on non-traditional IP networks. Thus, for example, a cloud can be based on a two-tier CLOS-based network with special single-tier IP routing that uses hashes of MAC addresses. The techniques described in this article can be used in such non-traditional clouds.

[0063] Generally, cloud computing infrastructure provides a virtual machine hosting environment that includes hosts (e.g., servers or similar physical computing devices) connected via a network and one or more management servers. Typically, each physical server is suitable for dynamically provisioning one or more virtual machines using virtualization technologies such as VMware ESX / ESXi. Multiple VMs can be placed on a single host and share the host's CPU, memory, and other resources, thereby increasing the utilization of an organization's data center. Among other tasks, the management server monitors the infrastructure and automatically manipulates VM placement as needed, such as by moving VMs between hosts.

[0064] In non-restrictive implementations, representative platform technologies include, but are not limited to, IBM Systems with VMware vSphere 4.1 Update 1 and 5.0. server.

[0065] Joint learning and threat model

[0066] Figure 4 illustrates a known method of distributed machine learning. The system includes a fusion (aggregation) server 400 and N data owners or agents 402, sometimes referred to herein as learning agents. In this embodiment, each learning agent has access to a local dataset d. _i (Typically composed of labeled samples), and want to train the same machine learning or neural network model. Each agent has its own dataset that it wants to protect and cannot share with other agents or aggregation servers. In typical operation, the distributed learning process can be performed as follows. In step (1), each agent 402 contacts the aggregation server 400 to obtain hyperparameters for training. In machine learning, hyperparameters are parameters whose values ​​are set before the learning process begins; conversely, the values ​​of other parameters are derived through training. Each agent 402 trains the same type of neural network. In a representative instance, the model associated with the agent is then trained by a parameter vector A = [p1…p...] consisting of several parameters. k Representation. The system contains multiple agents, among which A... i The parameter vector is given by agent i. In step (2), the i-th agent in its local dataset d _i The model is trained, and this training is typically done using mini-batches, which are small subsets of the overall training data. In doing so, the i-th agent computes its parameter vector A. i In step (3), each agent 402 sends the obtained parameters to the aggregation server 400, which then merges (typically by calculating the average or weighted average of the vectors) each parameter in the vector. This average can use different priorities (weights m) for different agents; for example, if agent i receives a weight m... i Then the average parameter vector calculated by the aggregation server is Σ i m i A i / Σ i m i In step (4), the aggregation server 400 publishes the average parameter vector back to the agent 402. Then, for a given number of iterations, steps (2)-(3) are repeated until the learning is considered complete.

[0067] It has been shown that the above process results in the creation of the same model if all data were collected at a single location and used to train the model for at least an additive loss function (i.e., an indicator loss function such as cross-entropy loss, norm-based loss, binary cross-entropy, etc.). However, this approach presents a challenge: it exposes the model to an aggregation server, which is typically a cloud-hosted service that may not be trusted by the data owner / agent, who may not themselves be located in the cloud. As described below, the multi-layered security techniques disclosed herein address this issue.

[0068] With further context, a key driver behind the emergence of federated learning was the need to address the privacy risks and constraints of centralized training, where training data must be collected from all parties and aggregated to a central server for training. In FL, training data remains distributed across each participant's local device. Participants (or parties) must agree on the model architecture and maintain their local training pipelines. Instead of providing raw training data to a central server, as shown in Figure 4, each party uses its private training data to train its local model and uploads model updates to the central server. Typically, an aggregator is also responsible for managing the parties, orchestrating training tasks, and merging model updates. Aggregated model updates are distributed to the parties so that their local models are (usually) synchronized after each training iteration.

[0069] The following provides further additional background on training DNNs in a distributed joint learning setting. Let θ represent the model parameters and L represent the loss function. Each party has its own training data / label pair (x... i ,y i Each party may choose to share gradients for a data batch with the aggregator. The aggregator calculates the sum of gradients from all parties and enables each party to synchronize its model parameters locally. This fusion algorithm is called FedSGD. Alternatively, each party can train locally for several epochs and pass the model parameters: Upload to the aggregator. This aggregator can calculate the weighted average of the model parameters. Where n i The size of the training data on i is the size of n, and n is the size of all n. i The aggregator then sends the aggregated model parameters back to the parties for synchronization. This model averaging fusion algorithm is called FedAvg. If only one batch of data is trained in a single FL training epoch and the model parameters are synchronized, FedAvg and FedSGD are equivalent because the gradient can be computed from the difference between the two consecutive uploaded model parameters. Because FedAvg allows the parties to batch multiple SGD iterations before synchronizing updates, privacy attacks become more challenging, as the model parameters are masked as more data is fed in.

[0070] The FedSGD and FedAvg algorithms involve only bijective summation and averaging operations. Simply put, if the model is represented as an array, these fusion algorithms perform coordinate-based fusion between the parties. That is, they add or average the parameters of model M1 from party P1 at index i with the parameters of model M2 from party P2 at the same index i—parameters across parties at a given index i can be fused without knowledge of any other indices. This allows the entire model update to be split into multiple fragments, deployed to multiple servers, and the same fusion algorithm to be performed independently. Furthermore, parameters or gradients can also be shuffled before aggregation, provided all parties perform the same permutations. For FL privacy attacks, the integrity of model updates and data ordering are critical to the optimized process of reconstructing the training data. The absence of either leads to reconstruction failure. As will be described, the techniques in this paper do not have such limitations, as only the splitting and permutation at the local side of each party are reversible.

[0071] Federation learning is typically used in cross-device and cross-silo scenarios. Cross-device federated learning (FL) training usually involves a large number of mobile devices or Internet of Things (IoT) devices acting as clients. Clients are highly unreliable. These devices may frequently connect and disconnect, and they are energy-constrained due to their frequent reliance on battery power. However, cross-silo FL training typically involves a fixed number of organizations sharing the incentives for collaborative learning models. They can provide reliable local training facilities. Therefore, the aggregator can maintain the state and address of each party with its unique ID. Cross-silo training places greater emphasis on data privacy, where strict data confidentiality is required. As will also be seen, the method presented in this paper addresses the problems in cross-silo FL training, but it is also applicable to cross-device domains.

[0072] The threat model in this paper assumes an honest but curious aggregation server. It is assumed that all parties involved in the FL training process are benign but do not tend to share training data with each other. An adversary attempts to inspect model updates uploaded from each party. The aim is to reconstruct the training data of all parties involved in FL training. This threat model is identical to that in FL privacy attacks. Furthermore, it is assumed that the parties involved in FL trust the System-on-Chip (SoC) hardware and the EVM that maintains the model aggregation workload.

[0073] System Design

[0074] The following details a representative design of the federated learning framework of this disclosure and describes how the method effectively mitigates information leakage channels used for FL privacy attacks. As described above, the framework preferably utilizes a multi-layered security approach, which includes (1) trusted aggregation, (2) distributed aggregation, and (3) dynamic permutation. The first aggregation technique is preferably transmitted via a remotely provable cryptographic virtual machine with runtime memory encryption (e.g., SEVEVM enables confidential and trusted aggregation. The Secure Encrypted Virtualization (SEV) used in this example embodiment is a computing technology introduced by AMD in 2016. Its purpose is to protect security-sensitive workloads in public cloud environments. SEV relies on AMD Secure Memory Encryption (SME) for runtime memory encryption. Combined with the AMD Virtualization (AMD-V) architecture, SEV can implement cryptographic isolation between guest VMs and hypervisors. Therefore, SEV can prevent higher-privileged system administrators (e.g., at the hypervisor level) from accessing data within the encrypted virtual machine domain. When SEV is enabled, the SEV hardware tagged all code and data of the VM with an Address Space Identifier (ASID), which is associated with a different Temporary Advanced Encryption Standard (AES) key called the VM Encryption Key (VEK). The key is managed by the AMD SP, a 32-bit ARM Cortex-A5 microcontroller integrated into the AMD SoC. Runtime memory encryption is performed via on-die memory controllers. Each memory controller has an AES engine that encrypts / decrypts data as it is written to main memory or read from the SoC. Control of memory page encryption is performed via page tables. Physical address bit 47 (also known as the C bit) is used to mark whether a memory page is encrypted. Similar to other TEEs, SEV also provides a remote authentication mechanism for authenticating the hardware platform and the guest VM to be booted. The authenticity of the platform is proven using an identity key signed by AMD and the platform owner. Before supplying any secrets, the guest VM owner verifies the authenticity of the SIM-enabled hardware and measures the UEFI firmware to help boot the encrypted virtual machine.

[0075] Figure 5 The general concept of confidential aggregation is described. It assumes the existence of isolated and independent trusted execution environments in the cloud (one of which is shown at 500), such as the above. Figure 3 Described cloud execution environments. TEEs such as the TEE500 allow users to outsource their computation to third-party cloud servers with trusted CPU packaging. Representative TEE technologies include, for example... SGX (Software Protection Extensions) / TDX (Trust Domain Extensions) SEV (as described above), PEF (Protected Execution Facility), ARM TrustZone, etc. TEE is particularly attractive for collaborative ML computation, where large amounts of privacy-sensitive training data, multiple distributors, and stricter data protection are rules. Here, and as will be described, TEE500 acts as a trusted medium for isolating the aggregator execution entity from other execution entities that facilitate joint learning.

[0076] like Figure 5As shown, TEE 500 is associated with an operating system-based container mechanism (e.g., open-source containers, such as Kata containers) for packaging and deployment, and its execution is an isolated virtual machine. Specifically, TEE 500 runs aggregator 502 within an encrypted virtual machine (EVM) 504 supported by runtime memory encryption (such as SEV) 506. Executing the aggregator within the TEE mitigates memory corruption attacks. Aggregator 502 is one of a set of distributed aggregators that includes the single aggregator depicted in Figure 4. Each aggregator (such as aggregator 502) executes within EVM 504, and the EVM memory is protected by a different Temporary Virtual Machine Encryption Key (VEK). In this way, the confidentiality of model aggregation computations is also protected from unauthorized users (e.g., system administrators) and licensed software (such as hypervisors or OS) running on the hosting server. As will be described, the parties 508 in the federated learning remotely authenticate the genuine SEV hardware / firmware and establish an end-to-end secure channel for exchanging model updates before participating in training. Specifically, remote certification facilitated by certification server 505 is used to provide hardware authentication and load-time integrity checks for the aggregator. Also, as depicted, each party 508 has data and its own machine learning (ML) infrastructure 510, and typically collaborates by exchanging attributes (e.g., model gradients).

[0077] With the foregoing background, the following provides a more detailed description of representative deployment examples of the federated learning framework used in this disclosure.

[0078] Representative deployment examples for federated learning frameworks are in Figure 6As shown in the figure. In this example, there are four (4) parties 600 (numbered 1 to 4) participating in the joint learning, and the aggregation mechanism is distributed among three (3) aggregator execution entities 602 (numbered aggregators 1 to 3). Each aggregator execution entity 602 executes within a TEE 604, and thus there are three TEEs (numbered TEEs 1 to 3). Similar to traditional joint learning, in the method of this paper, each party 600 needs to register with aggregator 602 to participate in training. Each party needs to verify the TEE platform, for example via remote proof, before registering. An aggregator execution entity first initiates the training process by notifying all parties. During the training phase, the aggregator participates in multiple training iterations with all parties. At each training iteration, each party first synchronizes its local model by downloading the latest model update from the aggregator, then uses the local training data to generate a new model update and uploads it to the aggregator. The aggregator merges the model updates from all parties and dispatches the aggregated version back to all parties. Once predetermined training criteria are met, such as the FL training reaching a specified number of training iterations, or once local model accuracy requirements are met, the parties can decide to exit FL training, and global training ends. Unlike traditional FL, deployment involves multiple aggregators 602 running within TEE 604, rather than a single central aggregator as shown in Figure 4. In this system, aggregators 602 need to communicate with each other for training synchronization. Furthermore, a proof server 606, responsible for verifying the workload of the aggregators and supplying secrets, is deployed, as will be described now.

[0079] Trusted Aggregation

[0080] As previously mentioned, model updates exchanged between parties and the aggregator can contain essential information for reverse engineering private training data. The following techniques are used to eliminate channels for adversaries to intercept and inspect model updates during transmission and while still in use. In this design, preferably, cryptographic segregation for FL aggregation is enforced via mechanisms such as (but not limited to) SEV. Figure 5 As noted, these aggregators execute within the EVM, and each EVM's memory is protected by a different ephemeral VEK. Figure 6 In the illustrated embodiment, establishing trust between aggregator 602 and parties 600 is divided into two phases:

[0081] Phase I: Launch Trust aggregator

[0082] First, the SIM EVM is securely launched using the aggregator running within it. To establish trust in the EVM, proof is provided that (1) the platform is genuine secure hardware providing the required security attributes (e.g., AMD SEV enabled), and (2) the Unified Extensible Firmware Image (UEFI) used to launch the EVM has not been tampered with. Once remote proof is complete, a secret is preferably provided to the EVM as a unique identifier for the trusted aggregator. This secret is injected into the EVM's encrypted physical memory and used for aggregator authentication in Phase II, as described below. Figure 6 In step (1), a proof server 606 is shown facilitating remote proof. For this purpose, the EVM owner instructs a service provider (e.g., The SP (Service Packet) derives the certificate chain, for example, from the Platform Diffie-Hellman Public Key (PDH) down to the root (e.g., the AMD Root Key (ARK)). This certificate chain can be verified using the root certificate. Furthermore, preferably, the UEFI image digest, SIM API version, and VM deployment policy are also included in the verification report along with the certificate chain.

[0083] The authentication report is sent to the authentication server 606, which is provided with a root certificate to verify the certificate chain for authenticating the hardware platform. Subsequently, the verification server 606 generates the initiating blob and the customer owner's Diffie-Hellman public key (GODH) certificate. These are sent back to the aggregation server 606 for negotiating the transmission encryption key (TEK) and transmission integrity key (TIK) via Diffie-Hellman Key Exchange (DHKE) and booting the EVM. UEFI measurements can be retrieved via the SP by pausing the EVM at boot time. This measurement is sent to the verification server 606 to verify the integrity of the UEFI boot process. Only after this does the verification server 606 generate an encapsulation secret, which preferably includes an ECDSA prime251v1 key. The hypervisor (not shown) injects this secret into the EVM's physical memory space as a unique identifier for the trusted aggregator and continues the boot process. The injection process for this secret preferably follows a remote verification protocol, such as the first-generation SEV remote verification protocol. Other remote verification protocols, such as the upcoming SIM-SNP, can be implemented to further enhance the integrity of the boot process.

[0084] Phase II: Aggregator Certification

[0085] All parties involved in FL must ensure they interact with a trusted aggregator protected by runtime memory encryption. To achieve aggregator authentication, and as described above, in Phase I, the proof server 606 configures its ECDSA private key as a secret during EVM deployment. This key is used to sign challenge requests and thus to identify legitimate aggregators. Figure 6 In step (2), before participating in the FL, one party first verifies the aggregator through a participation challenge request protocol. To do this, party 600 sends a randomly generated number to aggregator 602. Aggregator 602 digitally signs the random number using its corresponding ECDSA private key and then returns the signed random number to the requesting party. The party verifies that the random number is signed with the corresponding ECDSA public key. If the verification is successful, party 600 proceeds to register with aggregator 602 to participate in the FL. Furthermore, preferably, a secure channel is provided to protect communications between aggregators and between aggregators and parties for updating model parameters. Transport Layer Security (TLS) can be used to implement the secure channel to support mutual authentication between the party and the aggregator. In this way, all exchanged model updates are protected in use and transmission.

[0086] Dispersed aggregation with model segmentation

[0087] While enabling trusted aggregation offers significant advantages, it alone may not be sufficient, as there's no guarantee that the TEE is omnipotent and free from future security vulnerabilities. Therefore, a second security layer—distributed aggregation with model segmentation—enhances the system's resilience, ensuring that even if the TEE is compromised by data leakage, an adversary cannot reconstruct the training data from model updates. Now, let's reiterate... Figure 6 The representative implementations shown herein describe the above aspects of this disclosure in detail.

[0088] As previously explained, each aggregator 602 runs within the EVM and is only responsible for a portion of the model updates. Figure 6 In this example, three (3) aggregators are established, and as described above, each participant authenticates and registers with all aggregators respectively. Decentralized aggregation is implemented as follows in this example.

[0089] Training synchronization between aggregators A communication channel is maintained between aggregators for training synchronization, for example, in step (3). Any one of aggregators 602 can start a training iteration and becomes the initiator node by default. All other aggregators become follower nodes and wait for commands from the initiator. At each training iteration, the initiator first queries all parties to start local training and retrieves model updates for merging. Afterward, the initiator notifies all follower nodes to pull their corresponding model updates, aggregate them together, and distribute the aggregated updates back to the parties.

[0090] Decentralized aggregation does increase the cost of illegally obtaining model information at the aggregation point. Aggregators no longer maintain model architecture information; they only see numerical vectors. Furthermore, even missing a very small portion of model updates can completely negate a data reconstruction attack. Therefore, this protection scheme requires a trade-off between all TEE-protected aggregators to obtain the complete set of model updates.

[0091] While compromises for all TEE-protected aggregators are very difficult, the following description can be implemented to further protect federated learning from information leakage or other compromises with a third layer of security, dynamic permutation.

[0092] Dynamic replacement

[0093] Therefore, and to further obfuscate the information transmitted from all parties to the aggregator, a dynamic permutation scheme is preferably deployed to shuffle the segmented model updates at each training iteration (or some other defined period). As mentioned above, the dynamic permutation scheme is based on the insight that the order of parameters in the model update is irrelevant to the fusion algorithm, but they are crucial to the data reconstruction algorithm used in FL privacy attacks. With this data order obfuscated, it becomes infeasible for adversaries to generate reconstructed training data, even if they obtain the entire model update.

[0094] Random model segmentation .

[0095] exist Figure 7 The model partitioning and dynamic permutation are described therein, and are relative to the three (3) aggregators described therein. Specifically, aggregator 702 (aggregators 1 to 3) corresponds to Figure 6 Aggregator 602. Before training begins, an aggregator mapper 710 (data structure) is randomly generated for each DNN model to be trained. Each party selects a proportion of the model parameters for each aggregator, although this can be set to the default. Furthermore, local parties must allow mapper 710, and therefore this mapper 710 is shared by all parties participating in FL training. Figure 7 In this context, the first party has a trained local model 712. For example... Figure 7 As shown, and using mapper 710, the k parameters of the local model 712 are mapped to three aggregators, namely, aggregators {1-3} as shown, where the depicted shading and cross shading represent the aggregator attributes of each parameter within the model. As also shown, model updates are disassembled and rearranged for different aggregators. Figure 6Step (4) in the process generates shuffled partitions. The shuffled partitions are then uploaded to the appropriate aggregator and merged to generate aggregated partitions. After each party receives the aggregated model updates from different aggregators, they reverse-shuffle the aggregated model updates to the correct order. Then, the same mapper 710 is queried again to merge the model updates into their original positions within the local model. Figure 6 Step (5) in the process. Figure 7 In this paper, only one local model (trained and then merged) is described, but each party has its own local model construction.

[0096] Preferably, the dynamic permutation scheme shuffles the segmented model updates at each training iteration. Each permutation is seeded with a secret agreed upon across all parts (e.g., distributed via a trusted medium) and a dynamically generated training iteration ID. Therefore, preferably, the permutation changes between each training iteration but remains the same for all parties. In other words, the method in this paper preferably dynamically shuffles the model updates with deterministic permutations at each training iteration. An aggregator (i.e., the aggregator execution entity) merges the model updates, and the parties are responsible for restoring the order of the aggregated model updates. This method mitigates data leakage attacks by dynamically shuffling the order of uploaded model parameters. In this way, among other benefits, the method makes privacy protection of local training data more effective in joint learning.

[0097] Therefore, according to this aspect, preferably, the entire model update generated by one party is divided into multiple segments (partitions), wherein the partitions are deployed to multiple servers (aggregation execution entities) that independently execute the same fusion algorithm. Furthermore, parameters or gradients (or, more generally, elements) are also locally shuffled (i.e., permuted) before aggregation, provided that all parties perform the same permutation. It is only necessary that the parties can reverse the local segmentation and permutation. Local model update segmentation and permutation can be performed periodically, for example, at each training iteration or at some other defined period; alternatively, update segmentation and permutation occur asynchronously.

[0098] The partitioning of the entire local model into partitions and the permutation of one or more elements within each partition occur at each modeling iteration. All partitions may apply the same partitioning or different partitioning. Furthermore, partitioning and / or permutation strategies can be applied to centralized aggregators (where the number of aggregated entities equals 1); in such cases, there are no partitions, but weight permutations occur during model updates.

[0099] Generally, the dynamic permutation scheme described above facilitates aggregation fuzziness in joint learning. One party in the joint learning (or more generally, the first system in multiple systems participating in joint learning) determines which update vector (or more generally, the update) should be transmitted for fusion. A fuzzing algorithm is then applied to fuzz the update vector to generate a fuzzy update vector. A secret shared by each party can be used for this purpose, and each party in the joint learning uses the same shared secret to locally apply the fuzzing algorithm. For example, by... Figure 7 The examples illustrate how preferred obfuscation algorithms swap the element order of the update vector to produce obfuscated update vectors. As used herein, the concept of swapping element order is synonymous with shuffling or permutation. The obfuscated update vector is then sent to each aggregator execution entity (when multiple such entities are used to create a machine learning model). Updates can be performed with different element orders in each training iteration. While reordering the update vector elements is the preferred technique for obfuscation, other obfuscation algorithms can be used.

[0100] The techniques described herein offer significant advantages. As those skilled in the art will recognize, this approach protects and shields aggregations from reverse engineering attacks in federated learning while maintaining low overhead and supporting many different deep learning models and frameworks. Furthermore, the techniques presented here provide multiple structured and randomized model partitioning mechanisms to decompose the exchanged model parameters. Thus, even if a subset of the aggregator is compromised, adversaries are still prevented from reconstructing training data information. Moreover, the techniques enable learning participants to authenticate trusted hardware platforms and demonstrate resilience to federated learning workloads, thus further ensuring that sensitive data is not exposed and transmitted in the absence of end-to-end cryptographic protection. Compared to traditional FL training, the techniques presented here do not affect the final model accuracy and convergence rate. Simultaneously, the method significantly minimizes unnecessary exposure of one-way information to the aggregator, which is crucial for conducting FL privacy attacks.

[0101] As described above, the method presented in this paper leverages the unique arithmetic properties of federated learning algorithms and provides architectural and protocol enhancements to reduce potential information leakage channels. The described federated learning system preferably employs a three-layer security strategy: confidential and trusted aggregation, distributed model partitioning, and dynamic permutation of model updates. Federated learning systems implementing these security strategies are immune to training data reconstruction attacks.

[0102] Furthermore, while it is preferable to use all three techniques together, this is not necessary. Thus, the federated learning framework implementing the techniques of this disclosure can benefit from one or more of the following techniques and strategies. The first strategy achieves trustworthy and remotely verifiable model aggregation by leveraging confidential computation techniques. The second strategy involves distributing a single aggregator across multiple independent execution entities, preferably each having only a fragmented view of the model updates and being unaware of the model architecture. The third strategy provides support for randomization and dynamic permutation of the segmented model updates at each training iteration, rendering data reconstruction algorithms infeasible. By implementing all three layers of security strategies, and as described above, the system neutralizes prior art federated learning privacy attacks and exhibits low performance overhead in real-world deployments.

[0103] There are other advantages as well. One is that the distributed learning method does not require the generation of auxiliary inputs, and the training participants only share a subset of the fuzzy model parameters during the joint learning process. A trusted execution environment protects the confidentiality of the model updating data during transmission and aggregation. Furthermore, the method prevents malicious or compromised aggregation servers from reconstructing the training data of the joint learning participants. This method prevents both (i) honest but curious aggregators and (ii) malicious or compromised aggregators from reconstructing private training data from model updates. Another advantage is that the same method can be used for different FL tasks and can achieve the same level of training performance as the baseline.

[0104] The techniques described above can be implemented using any machine learning algorithm or computation that can be distributed in the manner described.

[0105] This topic can be implemented as a service, in whole or in part. In general, trusted and decentralized aggregations for federated learning functions can be provided as standalone functions, or they can leverage functionality from other ML-based products and services. For example, the security techniques described herein can leverage known services and solutions, such as the IBM Framework for Federation Learning (FFL), to support the described trusted aggregations, decentralized multi-aggregators with model partitioning, and dynamic model update permutations. Preferably, the aggregator application is containerized for easy deployment, although this is not mandatory. Kata containers can be used to deploy aggregator containers within a lightweight VM. Therefore, and as described, preferably, each aggregator container runs in a SEV-protected EVM (or equivalent). To provide TEE security functionality, and in this exemplary but non-limiting embodiment, an AMD EPYC 7642 (Rome) microprocessor running the firmware SEV API is used.

[0106] All or part of the above functionality can be implemented as a standalone method, such as a software-based function executed by a hardware processor, or it can be available as a management service (including as a web service via a SOAP / XML interface). The specific hardware and software implementation details described herein are for illustrative purposes only and are not intended to limit the scope of the described subject matter.

[0107] More generally, computing devices in the context of the disclosed subject matter are data processing systems (such as hardware and software) Figure 2 (As shown in the diagram), and these entities communicate with each other via networks such as the Internet, intranets, extranets, private networks, or any other communication medium or link. Applications on the data processing system provide native support for the Web and other known services and protocols, including but not limited to support for HTTP, FTP, SMTP, SOAP, XML, WSDL, UDDI, and WSFL. Information on SOAP, WSDL, UDDI, and WSFL is available from the World Wide Web Consortium (W3C), which is responsible for developing and maintaining these standards; further information on HTTP, FTP, SMTP, and XML is available from the Internet Engineering Task Force (IETF). Familiarity with these known standards and protocols is assumed.

[0108] The solutions described in this article can be implemented in or in combination with different server-side architectures, including simple n-tier architectures, security systems, web portals, and federated systems. It should also be noted that the techniques described herein can be practiced in loosely coupled server environments (including cloud-based environments), such as in combination with... Figure 3 As described.

[0109] More generally, the subject matter described herein can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment that includes both hardware and software elements. In a preferred embodiment, the functionality is implemented in software, including but not limited to firmware, resident software, microcode, etc. Furthermore, as described above, the context-based access control functionality can take the form of a computer program product accessible from a computer-usable or computer-readable medium that provides program code for use by or in conjunction with a computer or any instruction execution system. For the purposes of this description, a computer-usable or computer-readable medium can be any means that can contain or store programs for or in conjunction with an instruction execution system, apparatus, or device. The medium can be an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system (or apparatus or device). Examples of computer-readable media include semiconductor or solid-state memory, magnetic tape, removable computer disks, random access memory (RAM), read-only memory (ROM), rigid disks, and optical discs. Current examples of optical discs include compact disc-read-only memory (CD-ROM), compact disc-read / write (CD-R / W), and DVDs. Computer-readable media are tangible objects.

[0110] A computer program product may be a product having program instructions (or program code) for implementing one or more of the described functions. Those instructions or code may be stored on a computer-readable storage medium in a data processing system after being downloaded from a remote data processing system via a network. Alternatively, those instructions or code may be stored on a computer-readable storage medium in a server data processing system and are adapted to be downloaded via a network to a remote data processing system for use on a computer-readable storage medium within the remote system.

[0111] In a representative embodiment, the fusion server and each agent are implemented in a dedicated computer, preferably in software executed by one or more processors. The software is maintained in one or more data stores or memories associated with the one or more processors, and the software can be implemented as one or more computer programs. In general, the dedicated hardware and software include the functions described above.

[0112] While a specific order of operations performed by certain embodiments of the invention has been described above, it should be understood that such an order is exemplary, as alternative embodiments may perform operations in a different order, combine certain operations, overlap certain operations, etc. References to a given embodiment in the specification indicate that the described embodiment may include a particular feature, structure, or characteristic, but each embodiment may not necessarily include that particular feature, structure, or characteristic.

[0113] Finally, although the given components of the system have been described individually, those skilled in the art will understand that some functions can be combined or shared in a given instruction, program sequence, code section, etc.

[0114] The techniques described in this paper provide improvements to another technology or technology field (e.g., machine learning systems, security incident and incident management (SIEM) systems, other security systems), as well as improvements to automated cybersecurity analysis.

Claims

1. A joint learning method with reduced information leakage, wherein, Model updates provided by the participants were merged, including: The local model is split according to a mapper to generate a partition set, wherein the mapper maps the elements of the local model to a set of independent aggregator execution entities that commonly include an aggregator. The permutation operation is applied to one or more elements within each partition to generate a shuffled partition; During model updates, the shuffled partition is forwarded to the aggregator to execute the entity set; and After receiving the fused model update from the entity set executed by the aggregator, the fused local model is restored; The process of restoring the fused local model includes: adjusting the order of one or more elements in the fused model update to generate a reverse shuffle partition corresponding to the original position of the partition in the local model, and merging the reverse shuffle partition according to the mapper.

2. The method according to claim 1, further comprising dynamically repeating the permutation operation.

3. The method according to claim 2, wherein, The permutation operation is repeated at each training iteration.

4. The method according to claim 1, wherein, The permutation operation is based on a secret agreed upon by the participating parties, and the mapper is shared by all the participating parties.

5. The method according to claim 1, wherein, The element is one of the following: model parameters and model gradients.

6. The method according to claim 1, wherein, The permutation operation described herein is applied to adjust only a single model parameter.

7. A method for ensuring secure federated learning to prevent information leakage, comprising: Divide the aggregator into independent sets of aggregator execution entities; At the local computational entity associated with one of the parties participating in the joint learning, and wherein the model updates generated by the parties are fused in the aggregator: The local model is split according to a mapper to generate a partition set, wherein the mapper maps the elements of the local model to a set of independent aggregator execution entities that commonly include an aggregator. The permutation operation is applied to one or more elements within each of the partitions to generate a shuffled partition; and The shuffle partition is forwarded as the model update associated with the first party to the aggregator execution entity set; Specifically, the fused local model is restored by adjusting the order of one or more elements in the fusion model update to generate a reverse shuffle partition corresponding to the original position of the partition in the local model, and by merging the reverse shuffle partition according to the mapper.

8. The method of claim 7, further comprising: At the local computing entity, Receive the fusion model update set from the entity set executed by the aggregator; as well as Restore the merged local model.

9. The method of claim 7, further comprising repeating the permutation operation in each training iteration.

10. A device for federated learning, comprising: Hardware processor; Computer program instructions, which, when executed by the hardware processor, implement the method according to any one of claims 1-9.

11. A computer program product, comprising: Instructions that can be executed by a processor to cause the processor to perform the method according to any one of claims 1-9.

Images