-By Théo Ryffel, Andrew Trask, Morten Dahl, Bobby Wagner, Jason Mancuso, Daniel Rueckert, Jonathan Passerat-Palmbach
Abstract
A new framework for privacy preserving deep learning and discuss its assets. The framework puts a premium on ownership and secure processing of data and introduces a valuable representation based on chains of commands and tensors. This abstraction allows one to implement complex privacy preserving constructs such as Federated Learning, Secure Multiparty Computation, and Differential Privacy while still exposing a familiar deep learning API to the end-user. We report early results on the Boston Housing and Pima Indian Diabetes datasets. While the privacy features apart from Differential Privacy do not impact the prediction accuracy, the current implementation of the framework introduces a significant overhead in performance, which will be addressed at a later stage of the development. We believe this work is an important milestone introducing the first reliable, general framework for privacy preserving deep learning.
Paper provides a transparent framework for privacy preserving deep learning to every PyTorch user, enabling the use of FL, MPC, and DP from an intuitive interface. Showcases the ability of the framework to support various implementations of MPC and DP solutions and report the results obtained when instantiating the SPDZ and moment accountant methods respectively for MPC and DP in a federated learning context.
Contributions
- First build a standardized protocol to communicate between workers which made federated learning possible.
- Then, Develop a chain abstraction model on tensors to efficiently override operations (or encode new ones) such as sending/sharing a tensor between workers.
- Last, Provide the elements to implement recently proposed differential privacy and multiparty computation protocols using this new framework.
The chain structure Performing transformations or sending tensors to other workers can be represented as a chain of operations, and each operation is embodied by a special class. To achieve this, we created an abstraction called the SyftTensor. SyftTensors are meant to represent a state or transformation of the data and can be chained together. The chain structure always has at its head the PyTorch tensor, and the transformations or states embodied by the SyftTensors are accessed downward using the child attribute and upward using the parent attribute. Figure 1 presents the general structure of a tensor chain, where SyftTensors are replaced with instances of some subclasses which all have a specific role, like the LocalTensor class which will be described next. All operations are first applied to the Torch tensor which makes it possible to have the native Torch interface and they are then transmitted through the chain by being forwarded to the child attribute. There are two important subclasses of SyftTensor. First, the LocalTensor which is created automatically when the Torch tensor is instantiated. Its role is to perform on the Torch tensor the native operation corresponding to the overloaded operation. For instance, if the command is added, then the LocalTensor will perform the native torch command native_add on the head tensor. The chain has two nodes and it loops so that the LocalTensor child refers to the head node tensor which contains the data without needing the re-create a child tensor object, which would reduce performance. Second, the PointerTensor which is created when a tensor is sent to a remote worker. Sending and getting back a tensor is as simple as calling the methods send(worker) and get() on the tensor. When this happens, the whole chain is sent to the worker and replaced by a two-node chain: the tensor, now empty, and the PointerTensor which specifies who owns the data and the remote storage location. This time, the pointer has no child. Figure 2 illustrates how the chains are modified when being sent to a remote worker and how LocalTensor and PointerTensor are used in those chains.
Building an MPCTensor
The elements introduced in Section 2 form the building bricks necessary to create our MPCTensor. Splitting and sending the shares can be done using a list of PointerTensors. The MPC toolbox proposed in our framework implements the SPDZ protocol. The MPC toolbox includes basic operations such as addition and multiplication but also preprocessing tools to generate for instance triples used for multiplication, and more specific operations to neural networks including matrix multiplication. Some adjustments are made to the traditional elements of a convolutional network due to the specificities of MPC, we use average pooling instead of max pooling and approximate higher-degree sigmoid instead of relu as an activation function. Since the SPDZ protocol assumes that the data is given as integers, we added into the chain a node called the FixedPrecisionTensor that converts float numbers into fixed precision numbers. This node encodes the value into an integer and stores the position of the radix point. The complete structure of a tensor implementing SPDZ is summarized in figure 3. Unlike the MPC protocol, players are not equal in our framework since one is the owner of the model (called the local worker). He acts as a leader by controlling the training procedure on all the other players (the remote workers). To mitigate this centralization bias when dealing with data, the local worker can create remote shared tensors on data he doesn’t own and can’t see. Indeed, we expect remote workers to hold some data of their own in a general setting, for instance when hospitals are contributing medical images to train a model. Multiple players are then interested in seeing the execution performing correctly, which is particularly crucial during the inference phase where many factors could lead to corrupted predictions
Results and discussion
Table 1 reports the execution time required to train a neural network on the canonical Boston Housing dataset, using three declinations of our framework. A performance analysis denotes a reasonably small overhead for using Web Socket workers instead of Virtual Workers, thus validating their purpose of the notebook-developer tool. This is due to the low network latency when communicating between different local tabs. We are however 46 times slower than using regular PyTorch. We observe the same overhead in performance in our second experiment that trains a classifier to detect diabetes using the Pima Indian Diabetes dataset, a small dataset containing 768 rows and 8 columns. Table 2 shows how increasing improves the model at the expense of data privacy. The DP model achieves a 25-30 MSE compared to 20-24 in the baseline model, but the privacy guarantee remains strong as we achieve (0.5, 10−5 )-differential privacy. These results are consistent with those reported in the literature for computer vision applications. For the Boston Housing dataset, the baseline model spends approximately 19.8ms per batch while the differentially private model spends about 30.0ms, which is a very reasonable overhead (+50%) for a feature like privacy. One last observation that we can make is that the convergence is far slower with DP enabled. The MSE keeps value in the range of 500 over the first phase of 50 samplings. Then the MSE starts decreasing and steadily reaches a 10-50 MSE value. Two reasons can explain this behaviour: first, gradient clipping reduces the efficiency of the updates from the last layers, and second, the Gaussian noise interferes with the updates suggested by the gradients which are therefore less efficient. Note that raising the bound for gradient clipping also increases the variance of the Gaussian noise.
Conclusions
Introduced a privacy-preserving federated learning framework built over PyTorch. The design relies on chains of tensors that are exchanged between local and remote workers. Our tensor implementations support commands of the PyTorch API and combine MPC and DP functionalities within the same framework. There are still many issues to address, at the forefront of which is decreasing training time. Efficiency has not been tackled yet, but the current overhead suggests that there is room for improvement in what is a pure Python framework as opposed to high-level Python APIs that piggyback on optimised low-level libraries. Another concern has to do with securing MPC to make sure to detect and defeat malicious attempts to corrupt the data or the model. All code samples involved in this paper will be made available in a GitHub repository after satisfying the anonymisation requirements of the submission.Git Hub repository link
Comments