DP-BREM: Differentially-Private and Byzantine-Robust Federated Learning
with Client Momentum
Abstract
Federated Learning (FL) allows multiple participating clients to train machine learning models collaboratively while kee** their datasets local and only exchanging the gradient or model updates with a coordinating server. Existing FL protocols are vulnerable to attacks that aim to compromise data privacy and/or model robustness. Recently proposed defenses focused on ensuring either privacy or robustness, but not both. In this paper, we focus on simultaneously achieving differential privacy (DP) and Byzantine robustness for cross-silo FL, based on the idea of learning from history. The robustness is achieved via client momentum, which averages the updates of each client over time, thus reducing the variance of the honest clients and exposing the small malicious perturbations of Byzantine clients that are undetectable in a single round but accumulate over time. In our initial solution DP-BREM, DP is achieved by adding noise to the aggregated momentum, and we account for the privacy cost from the momentum, which is different from the conventional DP-SGD that accounts for the privacy cost from the gradient. Since DP-BREM assumes a trusted server (who can obtain clients’ local models or updates), we further develop the final solution called DP-BREM+, which achieves the same DP and robustness properties as DP-BREM without a trusted server by utilizing secure aggregation techniques, where DP noise is securely and jointly generated by the clients. Both theoretical analysis and experimental results demonstrate that our proposed protocols achieve better privacy-utility tradeoff and stronger Byzantine robustness than several baseline methods, under different DP budgets and attack settings.
1 Introduction
Federated learning (FL) [29] is an emerging paradigm that enables multiple clients to collaboratively learn models without explicitly sharing their data. The clients upload their local model updates to a coordinating server, which then shares the global average with the clients in an iterative process. This offers a promising solution to mitigate the potential privacy leakage of sensitive information about individuals (since the data stays local with each client), such as ty** history, shop** transactions, geographical locations, and medical records. However, recent works have demonstrated that FL may not always provide sufficient privacy and robustness guarantees. In terms of privacy leakage, exchanging the model updates throughout the training process can still reveal sensitive information [4, 31] and cause deep leakage such as pixel-wise accurate image recovery [51, 48], either to a third-party (including other participating clients) or the central server. In terms of robustness, the decentralization design of FL systems opens up the training process to be manipulated by malicious clients, aiming to either prevent the convergence of the global model (a.k.a. Byzantine attacks) [15, 3, 45], or implant a backdoor trigger into the global model to cause targeted misclassification (a.k.a. backdoor attacks) [2, 44].
To mitigate the privacy leakage in FL, Differential Privacy (DP) [12, 13] has been adopted as a rigorous privacy notion. Existing frameworks [30, 18, 26] applied DP in FL to provide client-level privacy under the assumption of a trusted server: whether a client has participated in the training process cannot be inferred by a third party from the released global model. Other works in FL [49, 26, 46, 41] focused on record-level privacy: whether a data record at a client has participated during training cannot be inferred by the server or other adversaries that have access to the model updates or the global model. Record-level privacy is more relevant in cross-silo (as versus cross-device) FL scenarios, such as multiple hospitals collaboratively learn a prediction model for COVID-19, in which case what needs to be protected is the privacy of each patient (corresponding to each record in a hospital’s dataset). In this paper, we focus on cross-silo FL with record-level DP, where each client possesses a set of raw records, and each record corresponds to an individual’s private data.
To defend against Byzantine attacks, robust FL protocols are proposed to ensure that the training procedure is robust to a fraction of potentially malicious clients. This problem has received significant attention from the community. Most existing approaches replace the averaging step at the server with a robust aggregation rule, such as the median [8, 47, 5, 32]. However, recent state-of-the-art attacks [3, 45, 38] have demonstrated the failure of the above robust aggregators. Furthermore, a recent work [22] shows that there exist realistic scenarios where these robust aggregators fail to converge, even if there are no Byzantine attackers and the data distribution is identical (i.i.d.) across the clients, and proposed a new solution called Learning From History (LFH) to address this issue. LFH achieves robustness via client momentum with the motivation of averaging the updates of each client over time, thus reducing the variance of the honest clients and exposing the small malicious perturbations of Byzantine clients that are undetectable in a single round but accumulate over time.
In this paper, we focus on achieving record-level DP and Byzantine robustness simultaneously in cross-silo FL. Existing FL protocols with DP-SGD [1] do not achieve the robustness property intrinsically. Directly implementing an existing robust aggregator over the privatized client gradients will lead to poor utility because these aggregators (such as median [47, 5, 32]) usually have large sensitivity and require large DP noise, leading to poor utility. It is desirable to achieve DP guarantees based on average-based aggregators. Although LFH [22] is an average-based Byzantine-robust FL protocol, it aggregates client momentum instead of gradient, thus it is non-trivial to achieve DP on top of LFH. We show that a direct combination of LFH with DP-SGD momentum has several limitations, leading to both poor utility and robustness. Therefore, we aim to address these limitations in our solution.
To achieve an enhanced privacy-utility tradeoff, we start our problem from an assumption that the server is trusted and developed a Differentially-Private and Byzantine-Robust fEderated learning algorithm with client Momentum (DP-BREM), which essentially is a DP version of the Byzantine-robust method LFH [22]. Instead of adding DP noise to the gradient and then aggregating momentum as post-processing, we add DP noise to the aggregated momentum with carefully computed sensitivity to account for the privacy cost. Since the noise is added to the final aggregate (instead of intermediate local gradient), our basic solution DP-BREM maintains the non-private LFH’s robustness as much as possible, which we show both theoretically (via convergence analysis) and empirically (via experimental results). Then, we relax our trust assumption to a malicious server (for privacy only) and develop our final solution DP-BREM+. It utilizes secure multiparty computation (MPC) techniques, including secure aggregation and secure noise generation, to achieve the same DP and robustness guarantees as in DP-BREM. In Table 1, we compare DP-BREM and DP-BREM+ with existing approaches (or the variants) that achieve both DP and Byzantine robustness (DDP-RP [43] and DP-RSA [50] are described in Sec. 7). These approaches will be evaluated and compared in experiments. Our main contributions are:
Approaches | Differential Privacy (DP) | Byzantine Robustness | |||
Trust Assumption of Server | Noise Generator | Perturbation Mechanism | Standard Deviation of Noise in Aggregate | Mechanism | |
DP-FedSGD [30] with both record and client norm clip**s | trusted | server | client norm clip** | ||
CM [47] with DP noise | trusted | server | coordinate-wise median (CM) | ||
DDP-RP [43] | honest-but-curious | clients (distributively) | element-wise range proof | ||
DP-RSA [50] | untrusted | client | aggregation of sign-SGD | ||
DP-LFH (baseline in Sec. 3.2) | untrusted | client | LFH [22]: client momentum and centered clip** | ||
DP-BREM (our initial solution) | trusted | server | |||
DP-BREM+ (our final solution) | untrusted | clients (jointly) | |||
-
We show the privacy-utility tradeoff by fixing the same privacy cost (in terms of DP) and then comparing the standard deviation of the noise on the aggregation, where a smaller standard deviation means the DP noise has less negative impact on the utility. Note that different approaches have different aggregation strategies, where denotes local gradient, and denotes local momentum.
-
DDP-RP assumes an honest-but-curious server, i.e., following protocol instructions honestly, but may try to learn additional information. It guarantees distributed DP (DDP) with secure aggregation techniques, where clients add partial noise with a smaller standard deviation, depending on the number of honest clients or its lower bound, denoted by . Thus, it provides better privacy-utility tradeoff than local DP (LDP).
-
DP-BREM+ achieves the same DP and robustness guarantees as DP-BREM, but has a different trust assumption on the server. It achieves the same noise as central DP, i.e., the DP noise is added to the aggregation, but does not require a trusted server because the noise is securely generated by clients (via the proposed noise generation protocol) and securely added to the aggregation (via a secure aggregation protocol).
1) We propose a novel differentially private and Byzantine-robust FL protocol called DP-BREM, which adds DP noise to the aggregated client momentum with carefully computed sensitivity. Our privacy analysis (shown in Theorem 1) accounts for the privacy cost from momentum, which is different from the conventional DP-SGD that accounts for the privacy cost from the gradient. We also provide the convergence analysis of DP-BREM (shown in Theorem 3), which indicates that there is only a small sacrifice in the convergence rate to satisfy DP (compared to the large sacrifice in convergence of the baseline solution shown in Section 3.2).
2) Considering that DP-BREM is developed under the assumption of a trusted server, we propose the final solution called DP-BREM+ (in Section 5), which achieves the same privacy and robustness properties as DP-BREM, even under a malicious server (for privacy only), using secure multiparty computation techniques. DP-BREM+ is built based on the framework of secure aggregation with verifiable inputs (SAVI) [35], but extends it to guarantee the integrity of DP noise via a novel secure distributed noise generation protocol. Our extended SAVI protocol is general enough to be applied to other DP and robust FL protocols that are average-based.
3) We conduct extensive experiments using MNIST and CIFAR-10 datasets (in Section 6) to demonstrate the effectiveness of our protocols. The results show that it can achieve better utility under the same record-level DP guarantees, as well as strong robustness against Byzantine clients under state-of-the-art attacks, compared to the baseline methods.
2 Preliminaries
2.1 Differential Privacy (DP)
Differential Privacy (DP) is a rigorous mathematical framework for the release of information derived from private data. Applied to machine learning, a differentially private training mechanism allows the public release of model parameters with a strong privacy guarantee: adversaries are limited in what they can learn about the original training data based on analyzing the parameters, even when they have access to arbitrary side information. The formal definition is as follows:
Definition 1 (-DP [13, 12]).
For and , a randomized mechanism with a domain (e.g., possible training datasets) and range (e.g., all possible trained models) satisfies -Differential Privacy (DP) if for any two neighboring datasets that differ in only one record and for any subset of outputs , it holds that
where and are privacy parameters (or privacy budget), and a smaller and indicate a more private mechanism.
Gaussian Mechanism. A common paradigm for approximating a deterministic real-valued function with a differentially-private mechanism is via additive noise calibrated to ’s sensitivity , which is defined as the maximum of the absolute distance . The Gaussian Mechanism is defined by , where is noise drawn from a Gaussian distribution. It was shown that satisfies -DP if and [13]. Note that we use an advanced privacy analysis tool proposed in [11], which works for all .
DP-SGD Algorithm. The most well-known differentially-private algorithm in machine learning is DP-SGD [1], which introduces two modifications to the vanilla stochastic gradient descent (SGD). First, a clip** step is applied to the gradient so that the gradient is in effect bounded for a finite sensitivity. The second modification is Gaussian noise augmentation on the summation of clipped gradients, which is equivalent to applying the Gaussian mechanism to the updated iterates. The privacy accountant of DP-SGD is shown in Appendix F.
2.2 Federated Learning (FL) with DP
Federated Learning (FL) [21, 29] is a collaborative learning setting to train machine learning models. We consider the horizontal cross-silo FL setting, which involves multiple clients, each holding their own private dataset of the same set of features, and a central server that implements the aggregation. Unlike the traditional centralized approach, data is not stored at a central server; instead, clients train models locally and exchange updated parameters with the server, which aggregates the received local model parameters and sends them to the clients. Based on the participating clients and scale, federated learning can be classified into two types: cross-device FL where clients are typically mobile devices and the client number can reach up to a scale of millions; cross-silo FL (our focus) where clients are organizations or companies and the client number is usually small (e.g., within a hundred).
FL with DP. In FL, the neighboring datasets and in Definition 1 can be defined at two distinct levels: record-level and client-level. In cross-device FL, each device usually stores one individual’s data, then the whole devices’ data should be protected. It corresponds to client-level DP, where is obtained by adding or removing one client/device’s whole training dataset from . In cross-silo FL, each record corresponds to one individual’s data, then record-level DP should be provided, where is obtained by adding or removing a single training record/example from . Since we consider cross-silo FL, achieving record-level DP is our privacy goal.
2.3 Byzantine Attacks and Defenses
In a Byzantine attack, the adversary aims to destroy the convergence of the model. Due to the decentralization design, FL systems are vulnerable to Byzantine clients, who may not follow the protocol and can send arbitrary updates to the server. Also, they may have complete knowledge of the system and can collude with each other. Most state-of-the-art defense mechanisms [8, 47, 5, 32] play with median statistics of client gradients. However, recent attacks [3, 45] have empirically demonstrated the failure of the above robust aggregations.
LFH: Non-private Byzantine-Robust Defense. Recently, Karimireddy et al. [22] showed that most state-of-the-art robust aggregators require strong assumptions and may not converge even in the complete absence of Byzantine attackers. Then, they proposed a new Byzantine-robust scheme called "learning from history" (LFH) that essentially utilizes two simple strategies: client momentum (during local update) and centered clip** (during server aggregation). In each iteration , client receives the global model parameter from the server, and computes the local gradient of the random dataset batch by
(1) |
where is the per-record gradient w.r.t. the loss function . The client momentum can be computed via
(2) |
where . After receiving from all clients, the server implements aggregation with centered clip** via
(3) |
where with scalar is the clip** function:
(4) |
and is the L2-norm of any vector . The clip** operation essentially bounds the distance between client’s local momentum and the previous aggregated momentum , thus restricts the impact from Byzantine clients. Then, the global model can be updated by with learning rate . The convergence rate under Byzantine attacks is shown by the following lemma.
Lemma 1 (Convergence Rate of LFH [22]).
With some parameter tuning, the convergence rate of the Byzantine-robust algorithm LFH is asymptotically (ignoring constants and higher order terms) of the order
(5) |
where is the loss function, is the total number of training iterations, is the number of Byzantine clients, is the number of all clients, and is a parameter that quantifies the variance of honest clients’ stochastic gradients:
(6) |
Interpretation of Lemma 1. When there are no Byzantine clients, LFH recovers the optimal rate of . In the presence of a fraction of Byzantine clients, the rate has an additional term , which depends on the fraction but does not improve with increasing clients.
3 Problem Statement and Motivation
3.1 Problem Statement
System Model. Our system model follows the general setting of Fed-SGD [29]. There are multiple parties in the FL system: one aggregation server and participating clients . The server holds a global model and each client , possesses a private training dataset . The server communicates with each client through a secure (private and authenticated) channel. During the iterative training process, the server broadcasts the global model in the current iteration to all clients and aggregates the received gradient/momentum from all clients (or a subset of clients) to update the global model until convergence. The final global model is returned after the training process as the output.
Threat Model. The considered adversary aims to perform a 1) privacy attack and/or 2) Byzantine attack with the following threat model, respectively.
1) Privacy Attack. Following the conventional FL setting, we assume the server has no access to the client’s local training data, but may have an incentive to infer clients’ private information. In our initial solution called DP-BREM, we assume a trusted server that can obtain clients’ local models/updates. The adversary is a third party or the participating clients (can be any set of clients) who have access to the intermediate and final global models and may use them to infer the private data of an honest client . Hence, the privacy goal is to ensure the global model (and its update) satisfies DP. In our final solution DP-BREM+, in addition to third parties and clients, the adversary also includes the server that tries to infer additional information from the local updates (and may deviate from the protocol for privacy inference). Such a model is also adopted in previous work [35]. Following [35], we assume a minority of malicious clients who can deviate from the protocol arbitrarily.
2) Byzantine Attack. Recall that the goal of Byzantine attacks is to destroy the convergence of the global model (discussed in Section 2.3). We only consider malicious clients as the adversaries for Byzantine attacks because the server’s primary goal is to train a robust model, thus no incentive to implement Byzantine attacks. These malicious clients (assumed to be a minority of all participating clients) can deviate from the protocol arbitrarily and have full control of both their local training data and their submission to the servers, but do not influence other honest clients.
Objectives. The goal of this paper is to achieve both record-level DP and Byzantine robustness at the same time. We aim to provide high utility (i.e., high accuracy of the global model) with the required DP guarantee under the existence of Byzantine attacks from malicious clients. Our ultimate privacy goal is to provide DP guarantees against an untrusted server and other clients, but we start by assuming a trusted server first in our initial solution.
3.2 Challenges and Baseline
Challenges: replacing average-based aggregator leads to large sensitivity of DP. Though there are many works on achieving either DP or Byzantine robustness, it’s nontrivial to achieve both with high utility. The main reason is that most Byzantine-robust methods replace the averaging aggregator with median-based strategies or some complex robust aggregators, which leads to a large sensitivity of DP compared to the averaging operation, as illustrated in Example 1.
Example 1 (Sensitivity Computation: Average vs. Median).
Consider a dataset with 5 samples: , and its neighboring dataset is obtained by changing one value in with at most 1, such as . Then, the sensitivity of average-query is . However, the sensitivity of median-query is . Moreover, when increasing the size of the dataset, the sensitivity of the average query will be reduced (and then less noise to be added), while the sensitivity of the median query is the same.
DP-LFH: baseline via direct combination of LFH and DP-SGD. As shown in Section 2.3, the Byzantine-robust scheme LFH [22] utilizes an average-based aggregator, which can be regarded as a non-private robust solution to address the disadvantage of median-based aggregator. A straightforward method to add DP protection on top of LFH is to combine it with the DP-SGD algorithm. However, LFH requires each client to compute the local momentum for server aggregation, while DP-SGD aggregates gradients and accounts for the privacy cost via the composition of iterative gradient update. Without a trusted server, a straightforward solution to combine DP with LFH is to use DP-SGD at each client to privatize the local gradient, and then compute the momentum from the privatized gradient (thus there is no additional privacy cost due to post-processing). Formally, client computes
(7) |
where is an identity matrix with size ( is the model size, i.e., ), the record-level clip** parameter restricts the sensitivity when adding/removing one record from the local dataset, and Gaussian noise introduces DP property on . Since DP is immune to post-processing, the remaining steps can be implemented in the same way as the original LFH, without incurring additional privacy costs. This baseline solution DP-LFH achieves record-level DP against an untrusted server. However, it has several limitations, which lead to both poor privacy-utility tradeoff and robustness.
Limitation 1: large aggregated noise. Since each client locally adds DP noise, the overall noise after aggregation will be larger than the case of the central setting under the same privacy budget (i.e., the value of ), because only the server adds noise in the central setting. Therefore, DP-LFH has a poor privacy-utility tradeoff.
Limitation 2: large impact on Byzantine robustness. Since the DP noise is added locally to each client’s gradient before momentum-based clip**, it leads to a negative impact on Byzantine robustness: the noisy client momentum has larger variance than the noise-free one, which leads to larger bias and variance on the clip** step . Furthermore, this impact will be enlarged when there are more Byzantine clients, which is explained as follows. Since the parameter defined in (6) quantifies the variance of client’s gradient, and the DP noise is added to the local gradient in (7), the parameter of the convergence rate shown in (5) is replaced by (ignoring constants) for DP-LFH, i.e., the convergence rate of DP-LFH is asymptotic of the order
(8) |
Therefore, either a large (i.e., large model) or a large (i.e., small privacy budget ) will enlarge the impact from Byzantine clients due to the order of convergence rate. We note that Guerraoui et al.’s work [19] also shares a similar insight: they show that DP with local noise and Byzantine robustness are incompatible, especially when the dimension of model parameters is large.
Limitation 3: no privacy amplification from client-level sampling due to momentum. According to the recursive representation , client ’s momentum in -th iteration is essentially a weighted summation of all previous privatized client gradients:
(9) |
where are already privatized via local noise. Assume the server samples a subset of clients for aggregation in each iteration. Assume that client ’s momentum is not selected in the -th iteration, thus the aggregate is independent of . However, in a later iteration (i.e., ), if client ’s momentum is involved in the aggregation, it will depend on according to (9). Therefore, we need to account for the privacy cost of in all iterations. There is no privacy amplification benefit from sampling clients, leading to high privacy costs or low utility.
4 DP-BREM
To address the limitations of DP-LFH, we start from the assumption of a trusted server that can obtain clients’ local models/updates and generate DP noise, and propose an initial solution called DP-BREM (in Section 4.1). It is a differentially-private version of LFH with carefully designed enhancements, achieving a similar level of robustness as the non-private LFH. Since DP-BREM adds DP noise to the momentum (as versus adding noise to the gradient in DP-SGD), our privacy accountant shown in Section 4.2 is different from the traditional privacy accountant of DP-SGD. We also provide the convergence analysis in Section 4.3, where the provable convergence of LFH is maintained with only a small difference. Based on DP-BREM, we then relax the server’s trust assumption in our final solution DP-BREM+ (in Section 5), by adopting secure multiparty computation techniques including secure aggregation with input validation and joint noise generation, which achieves the same DP guarantee with the same amount of noise as in DP-BREM, without trusting the server.
4.1 Algorithm Design
The mathematical notations involved in our algorithm design and theoretical analysis are summarized in Table 5 (see Appendix A). The illustration of our design is shown in Figure 1, and the algorithm is shown in Algorithm 1, where all clients need to implement local updates (in Line-3), but only a subset of their momentum vectors are aggregated by the server (in Line-4). The details of client updates and server aggregation are described below.
Client Updates. The client first samples a random batch from the local dataset with sampling rate , clips the per-record gradient by and multiplies the sum by a constant factor to get the averaged gradient
(10) |
where is the clip** function defined in (4), but is used here to bound the sensitivity for DP (refer to DP-SGD discussed in Section 2.1). Note that the batch size is random and . Then, the local momentum can be computed by
(11) |
where is the momentum parameter.
![Refer to caption](x1.png)
Server Aggregation. The server implements centered clip** with clip** parameter to bound the difference between client momentum and the previous noisy global momentum for robustness. Then, it adds Gaussian noise with standard deviation (thus the variance is ) to the sum of clipped terms to get the noisy global momentum
(12) |
where is an identity matrix with size , and only the sampled clients in (which is obtained in Line-2 of Algorithm 1 with sampling rate ) are aggregated in -th iteration. Note that adding noise to the summation of clipped client momentum is equivalent to adding noise to the average result . Then, the server updates the global model with learning rate
(13) |
Remark: clip** bounds and sampling rates. In our algorithm, we use two clip** bounds and two sampling rates. For clip** bounds, each client uses record-level bound to bound the per-record gradient in (10) for a finite sensitivity in record-level DP; while the server uses client-level bound to bound the difference between client momentum and the previous noisy global momentum in (12), which achieves Byzantine robustness as in LFH. For sampling rates, the client samples a batch of records from the local dataset with sampling rate , which provides privacy amplification for DP from record-level sampling; while the server samples a subset of clients with sampling rate (where the sampled clients set is denoted by ), which provides privacy amplification for DP from client-level sampling.
Remark: comparison with non-private LFH. Comparing with the original non-private Byzantine-robust method LFH [22] (see Section 2.3), our differentially-private version has three differences. First, comparing with (1), the client gradient in (10) is computed by averaging the clipped per-record gradient (with clip** bound ), which bounds the sensitivity of final aggregation when adding/removing one record from the local dataset. Second, comparing with (3), the server adds Gaussian noise when computing the aggregated global momentum in (12) to guarantee DP. Third, instead of aggregating all clients’ momentum, our method also considers aggregating a subset of them, reflected by the index set in (12). It provides additional privacy amplification from client-level sampling with sampling rate . Note that the original privacy amplification is provided by record-level sampling.
4.2 Privacy Analysis
Before presenting the final privacy analysis of DP-BREM, we first show how we compute the sensitivity for the summation of clipped client momentum in (12) for privacy analysis of one iteration, shown in Lemma 2. We note that clients may have different sizes of local datasets and can use different record-level sampling rates , thus the record-level sensitivity (denoted by ) for different clients can be different.
Lemma 2 (DP Sensitivity).
We use to denote L2-norm . In the -th round, denote the query function , where is public and . Consider the neighboring dataset that differs in one record from client ’s local data (), i.e., , then the sensitivity with respect to client is
(14) |
Proof.
(Sketch) According to (10), the sensitivity of is because each clipped term has bounded L2-norm, i.e., . Then, due to the recursive representation of local momentum in (11), the sensitivity of is . Finally, the client-level clip** introduces another upper bound for the sensitivity. Refer to Appendix A for the full-version proof. ∎
Remark: comparison with the privacy accountant of DP-SGD momentum. As discussed in Section 3.2, the privacy accountant of DP-SGD with momentum (i.e., account for privacy cost of gradient, then do post-processing for momentum) requires clients to add noise in the local gradients, which leads to poor utility especially when Byzantine attacks exist. In Lemma 2, we account for the privacy cost of aggregated momentum, where the sensitivity is carefully computed from the bounded record-level gradient. Therefore, our scheme solves the three limitations shown in Section 3.2, which is explained as follows. First, only the server adds noise (which is the same as the central setting), thus the privacy-utility tradeoff is not impacted. Second, the noise is added after the centered clip** , thus it only introduces unbiased error. We also show that (in Section 4.3) the impact from the added noise is separate from the impact from Byzantine attacks, as versus the impact from the local noise is enlarged with Byzantine attacks in DP-LFH (see Section 3.2). Third, since privacy is accounted on momentum, and only the aggregated momentum leaks privacy, our solution enjoys privacy amplification from client-level sampling.
The final privacy analysis of DP-BREM is shown in Theorem 1. It presents how to compute the privacy budget and privacy parameter when the parameters (such as , , , etc.) of the algorithm are given. We use an advanced privacy accountant tool called Gaussian DP (GDP) [11] (refer to Appendix F), then convert it to -DP. Note that in our privacy analysis, clients can use different record-level sampling rates , thus different sensitivity shown in (14). Therefore, the final privacy budget (denoted by ) of DP-BREM may be different for different clients, which provides personalized privacy if these parameters are different for each client.
Theorem 1 (Privacy Analysis).
DP-BREM (in Algorithm 1) satisfies record-level -DP for an honest client with and satisfying
(15) |
where denotes the cumulative distribution function (CDF) of standard normal distribution, and is defined by
(16) |
Proof.
This result is obtained by the composition of multiple iterations and the privacy amplification from sampling. See Appendix B for the detailed proof. ∎
4.3 Convergence Analysis
Before presenting the final convergence analysis of our solution, we first show the aggregation error for one iteration in Theorem 2.
Theorem 2 (Aggregation Error).
Denote as the ground truth aggregated raw momentum, where is the client momentum computed from gradient without record-level clip**. Assume the local momentum of all honest clients are i.i.d. with expectation , and the variance is bounded (in terms of L2-norm)
(17) |
After some parameter tuning (the detailed tuning is shown under (C) in Appendix C) of the clip** bounds:
(18) |
we have the following aggregation error due to clip**, DP noise, and Byzantine clients:
(19) |
where is the number of Byzantine clients, is the dimension of model parameter , is the noise multiplier (for DP) shown in (12), is the client-level sampling rate shown in Line-2 of Algorithm 1, and is defined in (17). The formal version of (19) is shown in (C) of Appendix C.
Proof.
(Sketch) Directly bounding is not easy, thus we utilize the upper bounds of and to get the final result, where is the expected local momentum (we assume clients’ local momentum are i.i.d.). When upper bounding , we can decompose it to three types of errors: error of honest clients (due to randomness and bias introduced by clip**), error of Byzantine clients (due to Byzantine perturbation), and error introduced by the added DP noise. Furthermore, we can have the optimized parameter tuning of and to minimize the summation of the above three types of errors. Refer to Appendix C for the full-version proof. ∎
Interpretation of Theorem 2. The value of quantifies the aggregation error, i.e., how the aggregated privatized momentum (with clip**, DP noise, and Byzantine clients’ impact) differs from the "pure" momentum aggregation , where only honest clients participate and without clip** and DP noise. According to (19), the aggregation error is proportional to and , where quantifies the variance of honest clients’ local momentum, is the fraction of Byzantine clients, and for -DP. In other words, the aggregation error will be enlarged when: honest clients’ variance is large, or the Byzantine attacker corrupts more clients, or the training model is complex (i.e., the model dimension is large), or we need stronger privacy (i.e., a smaller ), or the number of clients n is small. Furthermore, due to the format of , the impact from DP noise is independent of the increase of Byzantine clients (versus Limitation 2 of DP-LFH in Section 3.2). On the other hand, according to the parameter tuning in (18), we could theoretically set a smaller record-level clip** bound when , , and are large, or and are small. The tuning of client-level clip** bound should be adjusted according to the value of . Recall that is for DP, while is for robustness.
Where to add noise | Convergence Rate | |
LFH [22] | None | |
DP-LFH | Clients’ gradients | |
DP-BREM | Aggregated momentum |
By following the convergence analysis in [22] and using the result in (19), we have the convergence rate shown below.
Theorem 3 (Convergence Rate of DP-BREM).
Proof.
See Appendix D. ∎
Remark: comparison with LFH and DP-LFH. The convergence rate of the non-private LFH, DP-LFH, and the proposed solution DP-BREM, showing in (5), (8), and (20) respectively, are summarized in Table 2. Though both DP-LFH and DP-BREM pay an additional term of to get the DP property, they have different impacts on the convergence. As discussed in Limitation 2 of Section 3.2, the additional term of DP-LFH (due to DP noise added to clients’ gradient) is on the term , thus it will enlarge the impact of Byzantine clients (i.e., the term ). However, the additional term of our solution DP-BREM (due to DP noise added to the aggregated momentum) is on the term , which has a squared-root order. Therefore, DP noise only has a limited impact on the convergence of DP-BREM when there are Byzantine clients. We will validate the above theoretical analysis via experimental results in Section 6.
5 DP-BREM+ with Secure Aggregation
The private and robust FL solution DP-BREM (in Section 4) assumes a trusted server which can access clients’ momentum. In this section, we propose DP-BREM+, which assumes a malicious server and utilizes secure aggregation techniques, achieving the same DP and robustness guarantees as DP-BREM. As discussed in Section 3.1, we consider the server as malicious only for data privacy, while clients are malicious for both data privacy and Byzantine attacks.
5.1 Challenges
Considering the server is malicious for data privacy, the noisy aggregate of momentum with centered clip** shown in (12) must be implemented securely with the goals of 1) privacy, i.e., each party, including clients and the server, learns nothing but the differentially-private output; and 2) integrity, i.e., the output is correctly computed. Since the noisy aggregated momentum of the previous iteration already satisfies DP, we can regard it as public information and only need to focus on securely computing the term in (12).
Secure Aggregation with Verified Inputs (SAVI). The key crypto technique we leverage to achieve the above objectives is SAVI [35], which is a type of protocols that securely aggregate only well-formed inputs. The security goals include both privacy and integrity. Specifically, privacy means that no party should be able to learn anything about the raw input of an honest client, other than what can be learned from the final aggregation result. Integrity means that the output of the protocol returns the correct aggregate of well-formed input, where 1) an input passes the input integrity check with a public validation predicate if and only if , and 2) the aggregation is correctly computed. An instantiation of the SAVI protocol is EIFFeL [35] (described in Appendix G).
Challenge: Secure Generation of Gaussian Noise. A SAVI protocol can potentially solve the problem of securely aggregating the clipped vectors (by enforcing a norm-bound on the client momentum difference). However, the Gaussian noise needs to be securely generated and aggregated as well. In DP-BREM with a trusted server, the Gaussian noise is generated by the server to guarantee DP. However, when the server is assumed as malicious, the added Gaussian noise for DP cannot be directly generated by the server.
A straightforward solution is to follow [36] that assumes the existence of another semi-honest server (but does not collude with the original server) that will generate DP noise and execute the privacy engine. However, the assumption of another non-colluding server may not be practical and we assume only a single server.
Another alternative solution is to leverage Distributed DP (DDP) [39], where Gaussian noise is generated by clients in a distributed way: each client generates a Gaussian noise locally, and the aggregation of Gaussian noise also follows a Gaussian distribution with an enlarged standard deviation. Since only the aggregated result is released (with the help of crypto techniques), each client can add a smaller noise with the guarantee that the aggregated noise satisfies the required DP. However, this solution has two limitations in our scenario. First, distributed noise generation needs to add more noise to achieve the same privacy compared with server-side noise generation due to the collusion of malicious clients. Second, malicious clients can generate arbitrary values as the local Gaussian noise, which has a large impact on the robustness.
A possible solution to address the first limitation is to jointly generate Gaussian noise as in [34], where no party learns or controls the true value of the noise (or a portion of the noise). However, the protocol in [34] is designed only for additive secret sharing schemes, which only works for honest-but-curious parties and does not tolerate malicious parties. Moreover, in [34], the Gaussian noise is jointly generated by honest-but-curious and non-colluding parties, which does not address the second limitation as the clients can be malicious in our threat model discussed in Section 3.1.
Overview of DP-BREM+. To achieve secure aggregation with verified inputs and secure Gaussian noise generation under the threat model of a malicious server and malicious minority of clients, our DP-BREM+ 1) leverages an existing SAVI protocol called EIFFeL [35] to achieve secure input validation; and 2) introduces a new protocol to achieve secure noise generation that is compatible with EIFFeL. The idea of jointly generating Gaussian noise in DP-BREM+ is inspired by [34], but our design is based on Shamir’s secret sharing [37] with robust reconstruction by following the design in EIFFeL, thus guarantees security under malicious minority. We present the preliminaries of Shamir’s secret sharing and EIFFeL protocol in Appendix G.
5.2 Design of DP-BREM+
As discussed in Section 5.1, the main task of DP-BREM+ is to securely compute the term shown in (12). After computing local momentum via (11), each client first implements centered clip** to get , which is the private input for validation and aggregation.
Three-Phase Design. In DP-BREM+, clients and the server jointly implement three phases: 1) secure input validation to validate the client momentum is properly centered clipped by , 2) secure noise generation, where clients generate shares of Gaussian noise which can be aggregated in Phase 3 to ensure DP, and 3) aggregation of valid inputs and noise to obtain the noisy global model. We assume the arithmetic circuit is computed over a finite field . The illustration of DP-BREM+ is shown in Figure 2. Due to limited space, we present the detailed steps \small1⃝-\small7⃝ in Appendix H.
Phase 1: Secure Input Validation. The validation function for an input considered in DP-BREM+ is defined as , where if and only if the condition holds. Since honest clients compute , verifying whether is well-formed, with bounded L2-norm via , for all clients ensures centered clip** of client momentum (to achieve robustness as DP-BREM). We follow the design in EIFFeL [35] for secure input validation, which returns the validation result (either 1 or 0) for client ’s private input , corresponding to steps \small1⃝, \small2⃝, and \small3⃝ shown in Figure 2. Then, clients and the server can jointly verify all inputs , and obtain the set of valid inputs , where for all . In the later step, only inputs in are aggregated.
Phase 2: Secure Noise Generation. We develop a new protocol for secure distributed Gaussian noise generation, which returns the shares (held by each client) of a random vector of length from the Gaussian distribution , corresponding to steps \small4⃝ and \small5⃝ shown in Figure 2. The shares of noise can be reconstructed into a single Gaussian noise (for ensuring DP) with the guarantee that no parties know or control the generated noise, which protects the information of private inputs after the noisy aggregate is released.
Phase 3: Aggregation of Valid Inputs and Noise. Finally, the server and clients can aggregate the valid inputs (obtained in Phase 1) and the generated Gaussian noise (obtained in Phase 2) by implementing steps \small6⃝ and \small7⃝ shown in Figure 2, ensuring nothing except the noisy aggregate can be learned.
Remark on Efficiency. DP-BREM+’s usage of EIFFeL’s secure input validation is due to efficiency considerations. Instead of having clients perform clip** and using secure input validation, one alternative is to use standard secure multi-party computation (MPC) for the clip** and aggregation. However, doing this under MPC would result in a very large computation/communication overhead due to the multiplication, min-operation, division, and L2-norm computation in the clip** operation defined in (4). In contrast, the secure input validation protocol only requires the verifiers to check all the multiplication gates very efficiently with just one identity test. The compatibility with secure input validation is one of the advantages of DP-BREM.
Complexity. According to EIFFeL [35], the computation/communication complexity of secure aggregation with input validation is for clients and for the server in terms of the number of clients , number of malicious clients , and data dimension . For the proposed secure noise generation (only clients are involved), the computation/communication complexity for total clients is .
![Refer to caption](x2.png)
![Refer to caption](x3.png)
![Refer to caption](x4.png)
5.3 Security Analysis
In comparison, EIFFeL [35] is a secure aggregation protocol with verified inputs (without guaranteeing DP), while our solution DP-BREM+ is a secure noisy aggregation protocol with verified inputs and jointly generated Gaussian noise, which provides DP on the aggregated results. Therefore, the only difference is the Gaussian noise that will be aggregated to the final result. We show the formal security guarantee of DP-BREM+ in the following theorem.
Theorem 4 (Security Guarantees of DP-BREM+).
For the validation function considered in Section 5.2, given a security parameter , the secure noisy aggregation protocol in DP-BREM+ satisfies:
1) Integrity. For a negligible function , the output of the protocol returns the noisy aggregate of a subset of clients and Gaussian noise , such that all clients in have well-formed inputs:
where random vector , and for all . Note that the set contains all honest clients (denoted by ) and the malicious clients who submitted well-formed input (denoted by ), i.e., .
2) Privacy. For a set of malicious clients and a malicious server , there exists a probabilistic polynomial-time (P.P.T.) simulator such that:
where denotes the input of all the honest clients, denotes a random variable representing the joint view of all the parties in the protocol’s execution, indicates a polynomial-time algorithm implementing the "next-message" function of the parties in (see [35, Appendix 11.5]), and denotes computational indistinguishability. In summary, the server and clients do not learn anything besides the final aggregated result.
Proof.
See Appendix I. ∎
6 Experimental Evaluation
![Refer to caption](x5.png)
![Refer to caption](x6.png)
In this section, we demonstrate the effectiveness of the proposed DP-BREM/DP-BREM+ on achieving both good privacy-utility tradeoff and Byzantine robustness via experimental results on MNIST [25] and CIFAR-10 [24] datasets with non-IID setting (refer to Appendix J.1 for more details on the datasets and model architectures). All experiments are developed via PyTorch111Our source code will be available after the acceptance of the paper..
Byzantine Attacks. We consider four existing Byzantine attacks in our experiments, including ALIE ("a little is enough") [3], IPM (inner-product manipulation) [45], LF (label-flip**), and the state-of-the-art MTB ("manipulating-the-Byzantine") [38]. Refer to Appendix J.1 for more details.
Compared Methods. We compare the performance of six approaches against Byzantine attacks, including DP-BREM/+ (our approach)222Since DP-BREM+ achieves the same DP and robustness guarantees as DP-BREM, we did not perform the empirical experiments with secure aggregation because the accuracy results will be exactly the same as DP-BREM. We use DP-BREM/+ to denote both DP-BREM and DP-BREM+, and the implementation follows Algorithm 1., a variant of DP-FedSGD [30] with both record and client norm clip**, DDP-RP [43], DP-RSA [50], a variant of CM [47] with DP noise, and DP-LFH. The comparison (on trust assumption and mechanism overview) of these approaches is provided in Table 1, and Appendix J.1 shows more details of each approach. In summary, DP-BREM/+, DP-FedSGD, and DP-CM add central noise to the aggregation, but DP-BREM+ does not require a trusted server due to the secure aggregation technique. DDP-RP adds partial local noise to the client’s update with secure aggregation. DP-RSA and DP-LFH add local noise to the client’s update. We fix for -DP in all experiments. For the setting of other parameters, refer to Appendix J.2.
Evaluation Metric. We evaluate the testing accuracy of the global model within iterations. Considering the accuracy curve might be unstable under Byzantine attacks, we average the accuracy between and as the final accuracy for comparison. Note that both DP noise and Byzantine attacks reduce the accuracy. A protocol achieves good Byzantine robustness if its accuracy does not decrease too much with an increased number of Byzantine clients.
6.1 Robustness Evaluation with DP
We consider a fixed privacy budget and implement each attack with different percentages of Byzantine clients for the four attacks, and compare the accuracy among all approaches. The results for MNIST (with ) and CIFAR-10 (with ) datasets are shown in Figures 3 and 4. Though the detailed results differ under different attacks and for two datasets, we have some general observations:
1) When there is no attack, i.e., , DP-BREM/+ achieves almost the same accuracy as DP-FedSGD, indicating the Byzantine-robust design (client momentum with centered clip**) has almost no impact on the utility in this case.
2) After increasing , our DP-BREM/+ has the smallest accuracy decrease, indicating its success in providing Byzantine robustness. However, the accuracy of DP-LFH reduces sharply, demonstrating that the large aggregated local DP noise makes the robust aggregator more vulnerable to Byzantine attacks, which is consistent with our discussions of Limitation 2 in Section 3.2.
3) Though DP-FedSGD has client-level gradient clip**, which can restrict malicious clients’ impact, it is still vulnerable to some types of Byzantine attacks (such as IPM and MTB) under larger values.
4) CM with DP noise (or DP-CM) has a relatively small accuracy decrease for a relative small . It is the benefit of the median-based robust aggregator. But the sensitivity is larger than the average-based aggregators, as discussed in Example 1, the aggregated DP noise is too large to obtain a high accuracy, even when .
5) DDP-RP is more vulnerable to LF attack because it only checks the element-wise range. Also, the model replacement strategy in LF attack is more likely to change the positions that have small values in benign gradient vectors.
6) DP-RSA has relatively poor accuracy compared with other approaches, even when . It is caused by the sign-SGD aggregator, which only aggregates element-wise signs instead of values, leading to information loss. Moreover, the local DP noise makes the Byzantine attacks easier to succeed.
6.2 Privacy-Utility Tradeoff with Attack
We consider a fixed percentage of Byzantine clients for each attack under different values of privacy budget , and compare the accuracy of all approaches. The results for MNIST (with ) and CIFAR-10 (with ) datasets are shown in Figures 5 and 6. For both datasets, we consider four different levels of privacy, where means the standard deviation of DP noise is 0, but we still implement record-level clip** to illustrate how the noise affects the results while kee** other settings including the clip** step the same. Though the detailed results differ under different attacks and for two datasets, DP-BREM/+ has the best accuracy among all approaches, especially under IPM and MTB attacks. Note that when for DP noise (i.e., ), both DP-BREM/+ and DP-LFH reduce to LFH, thus they have the same results in this case. We can observe that with a moderate privacy budget, such as , DP noise only has a negligible impact on the accuracy. But if is too small, such as in Figure 5, DP-BREM/+ suffers a relatively larger impact (but still acceptable) from DP noise. Note that when there exist Byzantine attacks, reducing the DP noise to (i.e., ) does not significantly improve the accuracy of DP-BREM/+ compared with , because the performance is largely impacted by Byzantine clients’ perturbations. However, the accuracy of DP-LFH is greatly reduced when , since the local DP noise impacts the robustness of the aggregator. This observation is consistent with our theoretical analysis in Limitation 2 of DP-LFH (Section 3.2).
6.3 Other Results
Efficiency Evaluation of DP and Byzantine Robustness. We note that DP and Byzantine Robustness designs in our solution only introduce a small computation overhead, because 1) the clip** step of DP can be implemented efficiently; 2) our robustness is essentially a clipped summation of client momentum without any complex computations. Due to limited resources, we implemented the distributed training of FL on a single machine (by running all the clients and the server code sequentially). We evaluate the efficiency of DP-BREM via the running time (per round per client) on the MNIST dataset. The results shown in Table 3 indicate that the DP noise and Byzantine robustness only incur additional running time (depending on batch size).
Batch Size | Baseline (FedSGD) | FedSGD+DP (efficient2 ) | DP-BREM (DP+robust) | FedSGD+DP (inefficient3 ) |
30 | 11.80 | 13.31 | 13.72 | 41.06 |
60 | 18.23 | 19.79 | 20.27 | 76.70 |
120 | 31.22 | 33.18 | 33.70 | 149.32 |
-
1
Our GPU device is NVIDIA Tesla P100-PCIE-16GB. Using other GPU devices may have different results.
-
2
By default, our implementation uses efficient per-record gradient clip** by following Opacus library’s implementation with parallel clip** and optimized einsum (refer to https://opacus.ai/api/_modules/opacus/optimizers/optimizer.html#DPOptimizer)
-
3
To illustrate the improvement of efficient clip**, we also show the results of the inefficient implementation, which clips per-record gradient sequentially and without using optimized einsum.
Impact of in DP-BREM/+. Figure 7 (in Appendix J) shows how the accuracy changes w.r.t. the record-level clip** bound in DP-BREM/+. The results demonstrate that when there are fewer Byzantine clients (i.e., smaller ) or the noise multiplier is smaller (i.e., larger ), we need to set a larger to obtain better accuracy. This observation is consistent with the theoretical analysis of parameter tuning discussed in Theorem 2 and its interpretation.
Impact of in DP-BREM/+. In all previous experiments, we set client-level sampling rate by default. As discussed in Sec. 4.1, aggregating a subset of clients in (12) is one of the major differences from LFH. In Table 4, we show how the utility can be improved by this design under different attack percentages if we can choose an optimal (which can be regarded as a tunable parameter). Intuitively, when there is no attack, a smaller can provide more privacy amplification, i.e., a smaller is needed for the same value of in DP; but if is too small, the small aggregate population will lead to a larger variance of the aggregation. When there exists Byzantine attacks, a smaller value of can reduce the attack impact for each round because only a portion of Byzantine clients are selected for aggregation. Therefore, with increased , the optimal (highlighted in Table 4) is decreased.
0% | 0.503 | 0.525 | 0.504 | 0.491 | 0.485 |
10% | 0.435 | 0.434 | 0.465 | 0.449 | 0.438 |
20% | 0.255 | 0.284 | 0.297 | 0.328 | 0.241 |
7 Related Work
Due to limited space, we only discuss the most relevant defenses below and put other related work in Appendix K. Other works either only achieve DP or Byzantine robustness (but not both), or combine secure aggregation with Byzantine robustness without realizing DP.
Wang et al. [43] proposed an FL scheme (DDP-RP) to provide Distributed DP (via encryption) and robustness (via range proof technologies); however, this scheme only verifies whether the local model weights are in a bounded range, which provides weak robustness. In comparison, our solution utilizes client momentum and centered clip** to guarantee Byzantine robustness with provable convergence analysis. Zhu et al. [50] replaces the value aggregation with sign aggregation, which provides robustness because each client has a limited impact on the aggregation. The DP noise is added to the local gradient before the sign operation. Since it only aggregates the element-wise sign (instead of the value) of clients’ gradients, it has degraded convergence due to information loss. Also, [50] only accounts for the privacy cost of one iteration, instead of the composition of all iterations in FL. Thus, the privacy cost computed in [50] is underestimated. As a comparison, our solution is based on the original SGD (with momentum), and we account for the privacy cost of all iterations. Our experimental results have confirmed that DP-BREM outperforms both of these approaches.
8 Conclusions
This paper aims to achieve FL in the cross-silo setting with both DP and Byzantine robustness. We first proposed DP-BREM, a DP version of LFH-based FL protocol with a robust aggregator based on client momentum, where the server adds noise to the aggregated momentum. Then we further developed DP-BREM+ which relaxes the server’s trust assumption, by combining secure aggregation techniques with verifiable inputs and a new protocol for secure joint noise generation. DP-BREM+ achieves the same DP and robustness guarantees as DP-BREM, under a malicious server (for privacy) and malicious minority clients. We theoretically analyze the error and convergence of DP-BREM, and conduct extensive experiments that empirically show the advantage of DP-BREM/+ in terms of privacy-utility tradeoff and Byzantine robustness over five baseline protocols. In the future, we will extend our work to other types of robust aggregators.
References
- [1] Martin Abadi, Andy Chu, Ian Goodfellow, H Brendan McMahan, Ilya Mironov, Kunal Talwar, and Li Zhang. Deep learning with differential privacy. In ACM SIGSAC Conference on Computer and Communications Security (CCS), 2016.
- [2] Eugene Bagdasaryan, Andreas Veit, Yiqing Hua, Deborah Estrin, and Vitaly Shmatikov. How to backdoor federated learning. In AISTATS, 2020.
- [3] Gilad Baruch, Moran Baruch, and Yoav Goldberg. A little is enough: Circumventing defenses for distributed learning. 2019.
- [4] Abhishek Bhowmick, John Duchi, Julien Freudiger, Gaurav Kapoor, and Ryan Rogers. Protection against reconstruction and its applications in private federated learning. arXiv preprint arXiv:1812.00984, 2018.
- [5] Peva Blanchard, El Mahdi El Mhamdi, Rachid Guerraoui, and Julien Stainer. Machine learning with adversaries: Byzantine tolerant gradient descent. In NeurIPS, 2017.
- [6] George EP Box and Mervin E Muller. A note on the generation of random normal deviates. The annals of mathematical statistics, 1958.
- [7] Zhiqi Bu, **shuo Dong, Qi Long, and Weijie J Su. Deep learning with gaussian differential privacy. Harvard Data Science Review, 2020(23), 2020.
- [8] Yudong Chen, Lili Su, and Jiaming Xu. Distributed statistical machine learning in adversarial settings: Byzantine gradient descent. In ACM on Measurement and Analysis of Computing Systems, 2017.
- [9] Henry Corrigan-Gibbs and Dan Boneh. Prio: Private, robust, and scalable computation of aggregate statistics. In USENIX Symposium on Networked Systems Design and Implementation (NSDI), 2017.
- [10] Ronald Cramer, Ivan Damgård, and Yuval Ishai. Share conversion, pseudorandom secret-sharing and applications to secure computation. In Theory of Cryptography Conference (TCC), 2005.
- [11] **shuo Dong, Aaron Roth, and Weijie J Su. Gaussian differential privacy. To appear in Journal of the Royal Statistical Society: Series B (Statistical Methodology), 2019.
- [12] Cynthia Dwork, Frank McSherry, Kobbi Nissim, and Adam Smith. Calibrating noise to sensitivity in private data analysis. In Theory of Cryptography Conference (TCC), 2006.
- [13] Cynthia Dwork, Aaron Roth, et al. The algorithmic foundations of differential privacy. Now Publishers, 2014.
- [14] Cynthia Dwork, Guy N Rothblum, and Salil Vadhan. Boosting and differential privacy. In IEEE Annual Symposium on Foundations of Computer Science (FOCS), 2010.
- [15] Minghong Fang, Xiaoyu Cao, **yuan Jia, and Neil Gong. Local model poisoning attacks to byzantine-robust federated learning. In USENIX Security Symposium, 2020.
- [16] Paul Feldman. A practical scheme for non-interactive verifiable secret sharing. In IEEE Annual Symposium on Foundations of Computer Science (SFCS), pages 427–438, 1987.
- [17] Shuhong Gao. A new algorithm for decoding reed-solomon codes. Communications, information and network security, pages 55–68, 2003.
- [18] Robin C Geyer, Tassilo Klein, and Moin Nabi. Differentially private federated learning: A client level perspective. arXiv preprint arXiv:1712.07557, 2017.
- [19] Rachid Guerraoui, Nirupam Gupta, Rafaël Pinot, Sébastien Rouault, and John Stephan. Differential privacy and byzantine resilience in sgd: Do they add up? In ACM Symposium on Principles of Distributed Computing, 2021.
- [20] Lie He, Sai Praneeth Karimireddy, and Martin Jaggi. Secure byzantine-robust machine learning. arXiv preprint arXiv:2006.04747, 2020.
- [21] Peter Kairouz, H Brendan McMahan, Brendan Avent, Aurélien Bellet, Mehdi Bennis, Arjun Nitin Bhagoji, Kallista Bonawitz, Zachary Charles, Graham Cormode, Rachel Cummings, et al. Advances and open problems in federated learning. Foundations and Trends in Machine Learning, 14(1–2):1–210, 2021.
- [22] Sai Praneeth Karimireddy, Lie He, and Martin Jaggi. Learning from history for byzantine robust optimization. In ICML, pages 5311–5319, 2021.
- [23] Marcel Keller. Mp-spdz: A versatile framework for multi-party computation. In ACM SIGSAC Conference on Computer and Communications Security (CCS), pages 1575–1590, 2020.
- [24] Alex Krizhevsky, Geoffrey Hinton, et al. Learning multiple layers of features from tiny images. 2009.
- [25] Yann LeCun. The mnist database of handwritten digits. 1998.
- [26] Jeffrey Li, Mikhail Khodak, Sebastian Caldas, and Ameet Talwalkar. Differentially private meta-learning. In ICLR, 2020.
- [27] Shu Lin and Daniel J Costello. Error control coding. Prentice hall Lebanon, IN, 2001.
- [28] Yehuda Lindell and Ariel Nof. A framework for constructing fast mpc over arithmetic circuits with malicious adversaries and an honest-majority. In ACM SIGSAC Conference on Computer and Communications Security (CCS), pages 259–276, 2017.
- [29] Brendan McMahan, Eider Moore, Daniel Ramage, Seth Hampson, and Blaise Aguera y Arcas. Communication-efficient learning of deep networks from decentralized data. In AISTATS, 2017.
- [30] H Brendan McMahan, Daniel Ramage, Kunal Talwar, and Li Zhang. Learning differentially private recurrent language models. In ICLR, 2018.
- [31] Luca Melis, Congzheng Song, Emiliano De Cristofaro, and Vitaly Shmatikov. Exploiting unintended feature leakage in collaborative learning. In IEEE Symposium on Security and Privacy (S&P), 2019.
- [32] El Mahdi El Mhamdi, Rachid Guerraoui, and Sébastien Rouault. The hidden vulnerability of distributed learning in byzantium. In ICML, 2018.
- [33] Ilya Mironov. Rényi differential privacy. In IEEE Computer Security Foundations Symposium (CSF), 2017.
- [34] Sikha Pentyala, Davis Railsback, Ricardo Maia, Rafael Dowsley, David Melanson, Anderson Nascimento, and Martine De Cock. Training differentially private models with secure multiparty computation. arXiv preprint, 2022.
- [35] Amrita Roy Chowdhury, Chuan Guo, Somesh Jha, and Laurens van der Maaten. Eiffel: Ensuring integrity for federated learning. In ACM SIGSAC Conference on Computer and Communications Security (CCS), pages 2535–2549, 2022.
- [36] Amrita Roy Chowdhury, Chenghong Wang, Xi He, Ashwin Machanavajjhala, and Somesh Jha. Crypte: Crypto-assisted differential privacy on untrusted servers. In ACM SIGMOD International Conference on Management of Data (SIGMOD), 2020.
- [37] Adi Shamir. How to share a secret. Communications of the ACM, 22(11):612–613, 1979.
- [38] Virat Shejwalkar and Amir Houmansadr. Manipulating the byzantine: Optimizing model poisoning attacks and defenses for federated learning. In NDSS, 2021.
- [39] Elaine Shi, TH Hubert Chan, Eleanor Rieffel, Richard Chow, and Dawn Song. Privacy-preserving aggregation of time-series data. In Annual Network & Distributed System Security Symposium (NDSS), 2011.
- [40] **hyun So, Başak Güler, and A Salman Avestimehr. Byzantine-resilient secure federated learning. IEEE Journal on Selected Areas in Communications, 2020.
- [41] Stacey Truex, Nathalie Baracaldo, Ali Anwar, Thomas Steinke, Heiko Ludwig, Rui Zhang, and Yi Zhou. A hybrid approach to privacy-preserving federated learning. In ACM Workshop on Artificial Intelligence and Security, 2019.
- [42] Raj Kiriti Velicheti, Derek Xia, and Oluwasanmi Koyejo. Secure byzantine-robust distributed learning via clustering. arXiv preprint arXiv:2110.02940, 2021.
- [43] Fayao Wang, Yuanyuan He, Yunchuan Guo, Peizhi Li, and Xinyu Wei. Privacy-preserving robust federated learning with distributed differential privacy. In IEEE International Conference on Trust, Security and Privacy in Computing and Communications (TrustCom), 2022.
- [44] Hongyi Wang, Kartik Sreenivasan, Shashank Rajput, Harit Vishwakarma, Saurabh Agarwal, Jy-yong Sohn, Kangwook Lee, and Dimitris S Papailiopoulos. Attack of the tails: Yes, you really can backdoor federated learning. In NeurIPS, 2020.
- [45] Cong Xie, Oluwasanmi Koyejo, and Indranil Gupta. Fall of empires: Breaking byzantine-tolerant sgd by inner product manipulation. In Uncertainty in Artificial Intelligence, 2020.
- [46] Runhua Xu, Nathalie Baracaldo, Yi Zhou, Ali Anwar, and Heiko Ludwig. Hybridalpha: An efficient approach for privacy-preserving federated learning. In ACM Workshop on Artificial Intelligence and Security, 2019.
- [47] Dong Yin, Yudong Chen, Ramchandran Kannan, and Peter Bartlett. Byzantine-robust distributed learning: Towards optimal statistical rates. In ICML, 2018.
- [48] Hongxu Yin, Arun Mallya, Arash Vahdat, Jose M Alvarez, Jan Kautz, and Pavlo Molchanov. See through gradients: Image batch recovery via gradinversion. In CVPR, 2021.
- [49] Qinqing Zheng, Shuxiao Chen, Qi Long, and Weijie Su. Federated f-differential privacy. In AISTATS, 2021.
- [50] Heng Zhu and Qing Ling. Bridging differential privacy and byzantine-robustness via model aggregation. In International Joint Conference on Artificial Intelligence (IJCAI), 2022.
- [51] Ligeng Zhu, Zhijian Liu, and Song Han. Deep leakage from gradients. In NeurIPS, 2019.
Appendix A Proof of Lemma 2 (Aggregation Sensitivity)
Proof.
For the local momentum computation in (11), we can rewrite it as
For a neighboring dataset which differs only one record from client ’s data, i.e., , we denote the corresponding local gradient (with per-record gradient clip**) and momentum as and , respectively. Since is computed by (10) for , we have
where . Then,
where the first inequality is obtained by generalizing the triangle inequality; Therefore,
where is obtained due to for ; and is obtained according to Lemma 3. Now we finished the main proof of Lemma 2. ∎
Symbols | Description |
(global) model in -th iteration, where | |
local training data of client | |
data batch sampled from in -th iteration | |
client gradient and momentum at -th iteration | |
aggregation of among multiple clients | |
client gradient and momentum with record-level clip** | |
aggregation of with DP noise | |
record-level sampling rate (implemented by client ) | |
client-level sampling rate (implemented by the server) | |
record-level clip** bound (for DP) | |
client-level clip** bound (for robustness) | |
the set of honest clients that follow the protocol honestly | |
the set of Byzantine clients that are malicious | |
the percentage of Byzantine clients, i.e., |
The above proof used the following lemma.
Lemma 3.
For any vectors and , we have
where and denotes L2-norm.
Proof.
Our proof of Lemma 3 mainly uses the triangle inequality of a norm. Note that for L-2 norm , we have for any vectors and . We first show that , which is proved by enumerating all cases as follows.
Case 1. Assume and . Then,
Case 2. Assume and . Then, and
where . Therefore, in this case.
Case 3. Assume and . Then, and
where . Therefore, in this case.
Case 4. Assume and . Then,
where due to , and due to and . Therefore, in this case.
The Final Result. By summarizing all cases above, we have . On the other hand, since for any , it is obvious that
Thus, the upper bound of is . ∎
Appendix B Proof of Theorem 1 (Privacy Analysis)
Proof.
Since the added Gaussian noise in (12) has standard deviation , and the aggregation sensitivity is shown in (14), then the noise multiplier (defined by the ratio between Gaussian noise’s standard deviation and the sensitivity) is
Also, due to the client-level sampling (i.e., each client was selected by the server w.p. ) and record-level sampling (i.e., each record was selected by client w.p. ), the overall sampling rate is . Then, by applying the privacy accountant of Gaussian DP (GDP) [11] shown in Lemma 10 (see more details in Appendix F), DP-BREM satisfies -GDP with shown in (16). Finally, by converting -GDP to -DP via Lemma 9, we get (15), which finishes the proof. ∎
Remark: privacy accountant in practice. Eq. (15) provides the formula of when is given and is computed from (16). In practice, however, we need to compute the value of privacy budget with a fixed , where is conventionally set to be less than . In our experiments, we utilize the computation tool333https://github.com/woodyx218/Deep-Learning-with-GDP-Pytorch in [7] to solve from (15). For the value of in (16), we usually have in practice, then . In this case, the clip** bounds and are just hyperparameters that may affect the utility of the algorithm, but has no influence on the privacy analysis.
Appendix C Proof of Theorem 2 (Aggregation Error)
Before proving Theorem 2, we first show some notations and assumptions. In -th iteration, denote the selected honest clients and selected Byzantine clients . For momentum updates in -th iteration, we simplify the following notation (ignoring the subscript ) for convenience,
where is the client momentum computed from gradient with record-level clip**. Then, we can rewrite the noisy global momentum as , where .
We assume are i.i.d. with expectation and variance is bounded (in terms of L2-norm) . Therefore, the record-level gradient clipped ones are also i.i.d., and we denote the expectation . Due to the clip** operation, the variance is reduced, and we assume , where is the record-level clip** bound and is some positive constant. Also, there is a gap between and and we assume . We assume is not very far away from both and : and .
Proof.
Our proof heavily relies on several useful lemmas shown in Appendix E, where Lemma 4 splits the L2-norm of summation of vectors into weighted summation of vectors’L2-norm, and Lemma 5 provides the optimal strategy to choose these weights.
We first consider the bound of . Recall that the selected client set is , where the honest clients set and Byzantine clients set are disjoint. For any positive values with , we have
where used the fact that and ; used the result in Lemma 4. From the above inequality, the error can be decomposed into three terms: corresponds to the error of honest clients (who follow the protocol honestly) due to the randomness of clients’ training data and bias introduced by clip**, corresponds to the error of Byzantine clients (who submit arbitrary but will be clipped by the server), and corresponds to the error introduced by added Gaussian noise for privacy purpose. We will analyze each of the three errors in turn.
Bounding . Since for any random vector , we can rewrite as
where corresponds to the bias introduced by the clip** operations, and is the variance of honest clients’ submissions. Rewrite , where . Let be an indicator variable denoting if the momentum difference was clipped. Therefore, if , then and ; if , then and . Then, for each , we have
where
where is obtained by using Lemma 4 for any ; is obtained by taking . Therefore,
where is obtained from the definitions and ; is obtained by using Lemma 4 for any ; is derived from Jensen’s Inequality, i.e., for convex function ; is obtained by plugging in the previous two inequalities; is obtained by taking . Now, we can bound by:
where the first inequality is obtained by using Lemma 4. On the other hand, we can bound by
where used the assumption that are independent, then the random variables are also independent; used contractivity of a clip** (projection) step. Therefore,
where , and the second inequality holds with the assumption (thus we have )
Bounding . For any Byzantine client with , the error is bounded by the clip** step
where is obtained by using in Lemma 4 for any ; is obtained by the definition of and the assumption; is obtained by taking . Then, by using Lemma 4, we have
Bounding . Since the random noise , we have .
Putting into Together. Combining all terms, we have
(21) |
where is obtained by taking for , where ; is obtained by considering and taking the clip** bound , which makes the previous assumption holds; is obtained by taking , where and . Since and , we can approximate the tuning by .
The Final Result. On the other hand, we have
(22) |
where the first equality is obtained by the definition of ; the second equality is obtained by the fact that all honest clients’ momentum are independent with each other; and the third equality is obtained by the assumption for . Finally, we have
(23) |
where is obtained by using Lemma 4 for any ; is obtained from (C) and (C), where is defined in (C); is obtained by taking . Furthermore, if we assume and , we can rewrite (C) as the following version
which finishes the proof of Theorem 2. ∎
Appendix D Proof of Theorem 3 (Convergence Rate)
Proof.
Comparing with the aggregation error of (ignoring constants and higher order terms) in [22, Lemma 9], our aggregation error shown in (19) replaces the term by , which means a slower convergence due to DP noise. Then, following the result in [22, Theorem VI] and its informal version in (5), we get the convergence rate of our algorithm as in (20). Note that our aggregation utilizes a client-level sampling rate , i.e., approximate clients participate in the aggregation for one iteration. We need to replace the term of in (5) by in (20). ∎
Appendix E Useful Lemmas
Lemma 4.
For any positive real values and any -dimensional vectors , the following inequality holds
where denotes the L2-norm of a vector.
Proof.
Denote as the -th element of the vector , then we have
where the inequality is caused by Cauchy-Schwarz inequality. ∎
Lemma 5.
Consider the following optimization problem
where . Then, we have , where the optimal solution is .
Proof.
The augmented Lagrange function is . By taking Karush-Kuhn-Tucker (KKT) conditions, we have
then we have , which finished the proof. ∎
Appendix F Gaussian Differential Privacy (GDP)
Privacy Accountant. Since deep learning needs to iterate over the training data and apply gradient computation multiple times during the training process, each access to the training data incurs some privacy cost from the overall privacy budget . The total privacy cost of repeated applications of additive noise mechanisms follow from the composition theorems and their refinements [13]. The task of kee** track of the accumulated privacy loss in the course of execution of a composite mechanism, and enforcing the applicable privacy policy, can be performed by the privacy accountant. Abadi et al. [1] proposed moments accountant to provide a tighter bound on the privacy loss compared to the generic advanced composition theorem [14]. Another new and more state-of-the-art privacy accountant method is Gaussian Differential Privacy (GDP) [11, 7], which was shown to obtain a tighter result than moments accountant.
Gaussian Differential Privacy. GDP is a new privacy notion which faithfully retains hypothesis testing interpretation of differential privacy. By leveraging the central limit theorem of Gaussian distribution, GDP has been shown to possess an analytically tractable privacy accountant (vs. moments accountant must be done by numerical computation). Furthermore, GDP can be converted to a collection of -DP guarantees (refer to Lemma 9). Note that even in terms of -DP, the GDP approach gives a tighter privacy accountant than moments accountant. GDP utilizes a single parameter (called privacy parameter) to quantify the privacy of a randomized mechanism. Similar to the privacy budget defined in DP, a larger in GDP indicates less privacy guarantee. Comparing with -DP, the new notion -GDP can losslessly reason about common primitives associated with differential privacy, including composition, privacy amplification by sampling, and group privacy. In the following, we briefly introduce some important properties (that will be used in the analysis of our approach) of GDP as below. The formal definition and more detailed results can be found in the original paper [11].
Lemma 6 (Gaussian Mechanism for GDP [11]).
Consider the problem of privately releasing a univariate statistic of a dataset . Define the sensitivity of as , where the supremum is over all neighboring datasets. Then, the Gaussian mechanism , where , satisfies -GDP.
Lemma 7 (Composition Theorem of GDP [11]).
The -fold composition of -GDP mechanisms is -GDP.
Lemma 8 (Group Privacy of GDP [11]).
If a mechanism is -GDP, then it is -GDP for a group with size .
Lemma 9 (-GDP to -DP [11]).
A mechanism is -GDP if and only if it is -DP for all , where
and denotes the CDF of standard normal (Gaussian) distribution.
Lemma 10 (Privacy Central Limit Theorem of GDP [7]).
Denote as the sampling probability of one example in the training dataset, as the total number of iterations and as the noise scale (i.e., the ratio between the standard deviation of Gaussian noise and the gradient norm bound). Then, algorithm DP-SDG asymptotically satisfies -GDP with privacy parameter .
In this paper, we use -GDP as our primary privacy accountant method due to its good property on composition and accountant of privacy amplification in Lemma 10, and then convert the result to -DP via Lemma 9. We note that other privacy accountant methods, such as moments accountant [1] and Rényi DP (RDP) [33], are also applicable to the proposed scheme and theoretical analysis, but might lead to suboptimal results.
Appendix G Preliminaries for Crypto Primitives
Shamir’s Secret Sharing with Robust Reconstruction. Due to the assumption of a malicious minority, the utilized crypto primitives should be able to tolerate the wrong or missing messages of malicious clients. Shamir’s -out-of- Secret Sharing Scheme [37] allows distributing a secret among parties such that: 1) the complete secret can be reconstructed from any combination of shares; 2) any set of or fewer shares reveals no information about , where is the threshold of the secret sharing scheme. We denote as the share held by the -th party. Shamir’s secret sharing scheme is linear, which means a party can locally perform: 1) addition of two shares, 2) addition of a constant, and 3) multiplication by a constant. Furthermore, Shamir’s secret sharing scheme is closely related to Reed-Solomon error correcting codes [27], which is a group of polynomial-based error correcting codes. Shamir’s secret sharing scheme results in a Reed-Solomon code that can tolerate up to errors and erasures (message dropouts) such that . Given any subset of shares with up to errors, any standard Reed Solomon decoding algorithm, such as Gao’s decoding algorithm [17], can robustly reconstruct the secret . Due to the property of robust reconstruction, Shamir’s secret sharing is able to guarantee security with malicious minority (as versus additive secret sharing [10] guarantees security with honest-but-curious parties).
EIFFeL: An Instantiation of SAVI Protocol. EIFFeL [35] is a SAVI protocol (with privacy and integrity guarantees) that securely aggregates only well-informed inputs. Its threat model assumes a malicious server (for privacy only) and a set of malicious clients (for both breaching privacy and submitting malformed inputs) that can arbitrarily deviate from the protocol, while the remaining honest clients are assumed to follow the protocol correctly and have well-formed inputs. EIFFeL ensures privacy by using Shamir’s secret sharing scheme [37]. Integrity is guaranteed via 1) secret-shared non-interactive proofs (SNIP) [9], which is an information-theoretic zero-knowledge proof for secret-shared data; and 2) verifiable secret shares [16], which validates the correctness of the secret shares. Note that the original SNIP utilizes additive secret sharing scheme [10], and its deployment setting uses honest and non-colluding servers as the verifiers. In contrast, by leveraging Shamir’s secret sharing with robust reconstruction, EIFFeL extends SNIP to a malicious threat model in a single server setting, where all the other clients (some of them are malicious) and the server jointly act as the verifiers for the verification of client ’s input. Therefore, EIFFeL is compatible to our system model (a single server) and the threat model discussed in Section 3.1.
Appendix H Detailed Steps of DP-BREM+ in Figure 2
\small1⃝ Proof and Shares Generation: . For generating the proof, client first evaluates the circuit on its private input to obtain the value of every wire in the arithmetic circuit corresponding to the computation of , then uses these wire values to generate the proof (refer to [9, 35] for the detailed format). Then, client splits the private input and proof to generate shares and , and send them to other clients via Shamir’s secret sharing.
\small2⃝ Proof Summary Computation: . Each client except first verifies the validity of the received secret shares via verifiable secret shares [16], and then locally constructs the shares of every wire in via affine operations on the shares and to get the shares of proof summary (refer to [35] for the detailed format), which will be sent to the server.
\small3⃝ Proof Summary Verification: . After receiving shares of proof summary from clients , the server recovers the value of via robust reconstruction, which is resilient to incorrect shares submitted by the malicious clients, and then checks the values in proof summaries. Finally, the validation result if and only if has the correct value.
\small4⃝ Random Numbers Generation: . In this step, clients jointly generate the shares of -pairs of random numbers , where all of them are i.i.d. from uniform distribution in the range . Denote as the fractional precision of the power 2 ring representation of real numbers. To obtain the share of one random number , each client generates random bits in the binary filed , denoted by a binary vector with length , then generate and distributes the shares to other clients (via Shamir’s secret sharing). After receiving all shares from other clients, each client locally adds these shares to get , where vector is actually the bitwise XOR of vectors because the computation is implemented in the binary field . We define the binary vector as the binary representation of the fractional part of . Note that the Shamir’s secret sharing scheme of Phase 1 is implemented in a finite filed , where . Therefore, the client can locally compute the arithmetic share from the share of binary representation . Since all possible discrete values with power 2 ring representation evenly span the range , the generated random real number is uniformly distributed in .
\small5⃝ Transformation to Gaussian Distribution: . For each pair of , clients can jointly compute a secret sharing of and of by utilizing Secure Multiparty Computation (MPC) protocols [23] that guarantees security (i.e., privacy and integrity) with malicious minority. According to Box and Muller Transformation [6], and are i.i.d. random variables from the Gaussian distribution with mean 0 and variance 1. Then, by locally implementing secure multiplication with a constant (i.e., ), and are i.i.d random numbers following a Gaussian distribution with the desired standard deviation of . Finally, by concatenating shares of numbers in , clients obtains the shares of random vector with length from Gaussian distribution .
\small6⃝ Shares Aggregation: . Due to the linearity of Shamir’s secret sharing scheme, each client can locally compute the share of the noisy aggregate by adding the shares of all valid inputs and the share of Gaussian noise: , and sends that share to the server.
\small7⃝ Noisy Aggregate Reconstruction: . After receiving all shares of the noisy aggregate, the server recovers it using robust reconstruction.
Appendix I Proof of Theorem 4 (Security Analysis)
![Refer to caption](x7.png)
Integrity. We prove that DP-BREM+ satisfies the integrity constraint using the following lemmas, where Lemma 11 and Lemma 13 are derived from EIFFeL [35].
Lemma 11 (Integrity of Input).
DP-BREM+ rejects all malformed inputs with probability .
Lemma 12 (Integrity of Gaussian Noise).
In Phase 2 of DP-BREM+, each client holds the share of random vector that follows the Gaussian distribution .
Proof.
In the step \small4⃝ of Phase 2, the jointly generated random number follows uniform distribution in range as long as there is at least one honest client because ’s binary representation is the result of bitwise XOR of clients’ local random vectors . In step \small5⃝, since the utilized MPC protocol [23, 28] guarantees computation integrity (meaning that the output is correctly computed) with malicious minority, the uniform distribution generated in step \small4⃝ will be correctly transformed to Gaussian distribution. ∎
Since clients locally add shares of valid inputs and noise together, DP-BREM+ satisfies integrity of aggregate shown in Lemma 13. Our integrity guarantee in Lemma 13 directly follows EIFFeL [35], though the integrity of noise has different definition compared with the integrity of input. Note that the integrity of EIFFeL (and ours) relies on robust reconstruction property of Shamir’s secret sharing [37], and the details can be found from the paper[35].
Lemma 13 (Integrity of Aggregate).
The aggregated output of DP-BREM+ must contain the inputs of all honest clients and the generated Gaussian noise.
where random vector , is the set of all honest clients, is the set of malicious clients with well-formed inputs (i.e., )
Privacy. DP-BREM+ guarantees: nothing can be learned about a private input for an honest client , except:
1) passes the integrity check, i.e., .
2) anything that can be learned from the noisy aggregation of well-formed inputs (thus achieving the same DP guarantee as the original DP-BREM).
We prove this privacy property using the following lemmas, where Lemma 14 and Lemma 16 are derived from EIFFeL [35].
Lemma 14.
In Phase 1, for an honest client , DP-BREM+ reveals nothing about the private input except .
Lemma 15.
In Phase 2, DP-BREM+ reveals nothing about the generated Gaussian noise.
Proof.
In step \small4⃝, no entity learns the uniformly random number as long as there is at least one honest client due to the bitwise XOR operation. In step \small5⃝, nothing is revealed because the utilized MPC protocol [28] guarantees information theoretic privacy about the input shares during computation for distribution transmission. Note that the step \small5⃝ only generates the shares hold by clients without outputting the final result. ∎
Lemma 16.
In Phase 3, for an honest client , DP-BREM+ reveals nothing about the private input except whatever can be leaned from the noisy aggregate.
Appendix J Supplements of Experiments
![Refer to caption](x8.png)
![Refer to caption](x9.png)
J.1 Experimental Setup
FL Implementation. Due to limited resources, we simulate the distributed training of FL by running a single machine sequentially for clients and the server. The real-world implementation of FL is out of the scope of this paper.
Datasets (non-IID) and Model Architecture. We use two datasets for our experiments: MNIST [25] and CIFAR-10 [24], where the default value of the number of total clients is . For MNIST dataset, we use the CNN model from PyTorch example444https://github.com/pytorch/opacus. For CIFAR-10 dataset, we use the CNN model from the TensorFlow tutorial555https://www.tensorflow.org/tutorials/images/cnn, like the previous works [49, 30]. To simulate the heterogeneous data distributions, we make non-i.i.d. partitions of the datasets, which is a similar setup as [49] and is described below:
1) Non-IID MNIST: The MNIST dataset contains 60,000 training images and 10,000 testing images of 10 classes. There are 100 clients, each holds 600 training images. We sort the training data by digit label and evenly divide it into 400 shards. Each client is assigned four random shards of the data, so that most of the clients have examples of three or four digits.
2) Non-IID CIFAR-10: The CIFAR-10 dataset contains 50,000 training images and 10,000 test images of 10 classes. There are 100 clients, each holds 500 training images. We sample the training images for each client using a Dirichlet distribution with hyperparameter 0.9.
Byzantine Attacks. We consider four different Byzantine attacks in our experiments.
1) ALIE ("a little is enough") [3]. The attacker uses the empirical variance (estimated from the data of corrupted clients) to determine the perturbation range, in which the attack can deviate from the mean without being detected or filtered out.
2) IPM (inner-product manipulation) [45]. The attacker manipulates the submitted gradient to be the negative direction of the mean of other honest clients’ gradients, thus the negative inner-product of the true gradient and the aggregation prevents the descent of the loss. Note that the original IPM attack assumes the omniscient attacker (i.e., knows the data/gradient of all other clients), which is contradicted to our assumption that the attacker only has access to the data of the corrupted clients (otherwise, the privacy is already leaked and no need to provide DP). Thus, in the experiments, we use the data of corrupted clients to estimate the aggregated gradient of honest clients, and then manipulate the inner-product (i.e., non-omniscient attack).
3) LF (label-flip**). The attacker modifies the labels of all examples of corrupted clients’ data and trains a new model with multiple iterations, then uses model replacement strategy [2] to enhance the impact on the global model.
4) MTB ("manipulating-the-Byzantine") [38]. The attacker computes a benign reference aggregate using some benign data samples obtained from corrupted clients, then computes a malicious perturbation vector, and an optimized scaling factor to get the malicious update with the goal of evading detection by robust aggregation algorithms. The optimization of the scaling factor can be tailored or agnostic to the aggregator. Considering our scheme and the baselines do not detect malicious clients, we use the agnostic setting (including min-max and min-sum) for simplicity because tailoring MTB attack to all defense aggregators is nontrivial. In our experiments, we implement the min-max attack since it has a larger impact on the global model.
Byzantine Defenses with DP. We compare the performance of our approaches with the following five competitors against Byzantine attacks. All of them satisfy record-level DP via record-level clip** and DP noise added to the local gradient/momentum. Note that privacy budget in Theorem 1 is the same for different clients because clients have the same size of local datasets and same record-level sampling rate (i.e., same and for different clients ).
1) DP-FedSGD. Note that the original DP-FedSGD in [30] clips the client gradient to achieve client-level DP. For a fair comparison, we also implement record-level gradient clip** on top of the original DP-FedSGD to guarantee record-level DP. Though DP-FedSGD is not designed for robustness, its client-level clip** can restrict malicious clients’ capability, thus providing some level of Byzantine robustness. We take this as a baseline to illustrate that client-level clip** can provide some level of robustness, but may not be enough to defend against strong attackers (either advanced attack strategy or a larger number of malicious clients).
2) DP-CM. As a baseline that adds DP to median-based robust aggregators (discussed in Section 3.2), we implement the Byzantine-robust aggregator Coordinate-wise Median (CM) [47] with DP noise added to the median result. Note that only DP-CM uses median-based aggregation, while other methods use average-based aggregation. As discussed in Section 3.1 and Example 1, the median-based aggregation has large sensitivity and poor privacy-utility tradeoff.
3) DDP-RP [43]. By leveraging encryption techniques, DDP-RP guarantees Distributed DP with secure aggregation. It allows clients to add smaller noise in the local gradient than the Local DP, with the knowledge of the lower bound of trusted clients, thus providing enhanced privacy-utility tradeoff than local DP protocols. To guarantee Byzantine robustness, DDP-RP uses range-proof (RP) technologies to securely verify whether the local model/gradient weights are in a (predefined) bounded range.
4) DP-RSA [50]. It replaces the value aggregation to sign aggregation, which provides robustness because each client has limited impact on the aggregation. The DP noise is added to the local gradient before the sign operation.
5) DP-LFH. The baseline (shown in Section 3.2) directly combines DP-SGD based momentum with LFH. Each client adds DP noise to the local gradient, and then computes the local momentum that will be aggregated with centered clip** by the server.
J.2 Parameters Setting
Basic Parameters.
-
•
Total number of iterations : 1000 for MNIST; 2000 for CIFAR-10
-
•
Learning rate : For MNIST datasets, is linearly reduced from 0.1 to 0.01 w.r.t. iterations. For CIFAR-10 dataset, is linearly reduced from 0.05 to 0.0025 w.r.t. iterations.
DP-related Parameters.
-
•
Record-level sampling rate : 0.05 for all
-
•
Client-level sampling rate : the default value is 1. We evaluate the influence of (from 0.2 to 1) on the accuracy in Table 4.
- •
-
•
Privacy parameter in DP:
-
•
Noise multiplier : For MNIST (with and each client has examples), for . For CIFAR-10 (with and each client has examples), for .
Robustness-related Parameters.
-
•
Client-level clip** bound (only for DP-BREM and DP-LFH): linearly reduced from to w.r.t. iterations, where for MNIST, and for CIFAR-10.
-
•
Momentum parameter
J.3 More Experimental Results
Appendix K Other Related Work
FL with DP. Differential Privacy (DP) was originally designed for the centralized scenario where a trusted database server, which has direct access to all client’s data in the clear, wishes to answer queries or publish statistics in a privacy-preserving manner by randomizing query results. In FL, McMahan et al. [30] proposed DP-FedSGD and DP-FedAvg, which provide client-level privacy with a trusted server. Geyer et al. [18] uses an algorithm similar to DP-FedSGD for the architecture search problem, and the privacy guarantee acts on client-level and the trusted server too. Li et al. [26] studies online transfer learning and introduces a notion called task global privacy that works on record-level. However, the online setting assumes the client only interacts with the server once and does not extend to the federated setting. Zheng et al. [49] introduced two privacy notions, that describe privacy guarantee against an individual malicious client and against a group of malicious clients (but not against the server) on record-level privacy, based on a new privacy notion called -differential privacy. Note that, our solutions achieve record-level DP under either a trusted server or a malicious server.
Byzantine-Robust FL. Recently, there have been extensive works on Byzantine-robust federated/distributed learning with a trustworthy server, and most of them play with median statistics of gradient contributions. Blanchard et al. [5] proposed Krum which uses the Euclidean distance to determine which gradient contributions should be removed. Yin et al. [47] proposed two robust distributed gradient descent algorithms, one based on the coordinate-wise median, and the other on the coordinate-wise trimmed mean. Mhamdi et al. [32] proposed a meta-aggregation rule called Bulyan, a two-step meta-aggregation algorithm based on the Krum and trimmed median, which filters malicious updates followed by computing the trimmed median of the remaining updates.
Private and Byzantine-Robust FL. Recently, some works tried to simultaneously achieve both privacy and robustness of FL. He et al. [20] proposed a Byzantine-resilient and privacy-preserving solution, which makes distance-based robust aggregation rules (such as Krum [5]) compatible with secure aggregation via MPC and secret sharing. So et al. [40] developed a similar scheme based on Krum, but rely on different cryptographic techniques, such as verifiable Shamir’s secret sharing and Reed-Solomon code. Velicheti et al. [42] achieved both privacy and Byzantine robustness via incorporating secure averaging among randomly clustered clients before filtering malicious updates through robust aggregation. However, these works only ensure the security of the aggregation step and do not achieve DP for the aggregated model.