Table of Contents
- 1.0 Overview and Literature Review
- 2.0 Goals and Non-Goals
- 2.0.1 Goals:
- 2.0.2 Non-Goals:
- 3.0 Milestones:
- Build prototype of fortified FL solution
- Test prototype of fortified FL solution
- 4.0 Framework / Design:
- 4.0.1 Assumptions
- 4.0.2 Adversarial attacks:
- 4.0.2 Chosen data for modelling
- 4.0.3 Defence mechanism against the chosen adversarial attacks:
- 4.0.4 Experimentation design:
- 4.0.5 Defence mechanism performance metrics:
- 5.0 References:
- Results of Framework Implementation – Adversarial Fortification
- Assumptions of the framework
- 2.0 Adversarial attack strategies
- 3.0 Chosen data and model for FL training:
- 4.0 Metrics for adversarial attack
- 5.0 Data Poisoning (DP) attack
- 5.0.1 Mechanism of DP
- 5.0.2 Parameters considered for DP attack.
- 5.0.3 Take home points from DP attack.
- 6.0 Byzantine (BY) attack
- 6.0.1 Mechanism of BY
- 6.0.2 Parameters for the BY attack
- 6.0.3 Take home points from BY attack
- 7.0 DP + BY attack
- 7.0.1 Mechanism of DP + BY attack
- 7.0.2 Parameters for the DP + BY attack
- 7.0.3 Take home points from comparison analysis
- 8.0 Defence mechanism
- 8.0.1 Different defence mechanism considered
- 8.0.2 Take home points from defence mechanism
- 9.0 Summary and outlook
- 10. References
1.0 Overview and Literature Review
In the last 5 years, there has been a dramatic growth and adoption of Internet of Things (IoT) devices like smartphones, smart meters, industrial machinery, energy infrastructure, autonomous vehicles. Each devices generates high amounts of data which are being used for different machine learning (ML) / artificial intelligent (AI) services with proper data privacy and security. In most of the cases, clients do not want to share their private data to the server due to the sensitive nature of the data. Federated learning (FL) allows a server to learn a ML model across multiple decentralized clients that privately store their own training data and thus do not require the clients to outsource their private data to server.
FL indeed offers an alternative solution than the traditional centralized ML approaches, but it is not completely immune to different kinds of adversarial attacks. In FL settings, in each training epoch, the server calculates a global update of the model parameters upon receiving local updates from clients who get the local updates by using their data in a private setting. The local model updates sent by clients might leak confidential information of the client’s private data. On the other hand, a single or group of malicious clients can try to poison the model by sending local model updates trained on wrong data or prevent the global model from converging. These are serious open problems which need to be addressed in order to earn clients’ trust and maintain a secure rich environment in order to get best results to maximize economic and other value potentials.
OctaiPipe has combined FL, automated ML and fault tolerant Edge MLOps to automate the entire ML lifecycle on device or connected machine in a secure and privacy preserving way. Hence it is extremely important for us to tackle the possible adversarial attacks regarding FL in order to deliver a platform that is more private and secure.
In this design template, we are describing a framework for testing and architecture fortification against adversarial attacks and mitigation in FL, starting from the goal to testing procedures and open questions.
2.0 Goals and Non-Goals
2.0.1 Goals:
- Developing FL framework/sandbox with different kind of adversarial attacks and implementing one of some countermeasure techniques to further assess the improvements or changes to the attacked framework.
- We will not be using FL implemented OctaiPipe platform to test the attacked FL framework and possible solutions, rather will use an independent python environment to test the framework.
- The future goal is to implement the counterattack measurement to the OctaiPipe platform to make it more secure and private.
2.0.2 Non-Goals:
- The FL architecture will be strictly a server-client based architecture which means we will not be considering a peer-to-peer FL or any other kind of hierarchical architecture.
- The coding language will be Python and we will be using Flower package for FL. No other coding language or FL packages will be considered.
- We will not address any privacy concerns. We will assume that the malicious client(s) is just trying to corrupt the global model into false prediction. The malicious client(s) is not trying to extract sensitive information from the benign clients’ dataset (privacy attack) or is not launching an attack on the global server in order to extract information about benign client(s).
3.0 Milestones:
4.0 Framework / Design:
4.0.1 Assumptions
- Suppose we have (say 5 to 7) independent clients, each having their private data which are assumed to be identical and independently distributed (i.i.d.). The clients’ raw and private data never leave their devices.
- A model manager, sitting in the central server, initializes a learning model, say neural network with some hyperparameters. At the starting point of training session, clients will ask for the hyperparameters from the server through a secure channel and will train the same model with their respective private data separately.
- After some training epochs, the clients will send their updates …, to the model manager who updates the global model by averaging/aggregating the updates. Note that, only some fraction of clients (say 2 to 3), randomly chosen, are participating in sending their updates in the above fashion.
- The model manager will send the global model update to all the clients which the clients will further use to train the model using their private data separately.
- This training process will continue until the global model reach to a satisfactory level of optimization / convergence.
- Note that, the model manager or the server controls neither the private input of each client nor the updates …, which opens a window of opportunity for potentially malicious clients. We assume that the model manager has no interest in perturbing or damaging the resulting model which means that the FL server is honest.
- On the contrary, the clients can be malicious and can thus deviate from the protocol, typically by modifying either their data or their individual updates.
4.0.2 Adversarial attacks:
As mentioned in the previous section, adversarial attacks can come from malicious clients, either a single client or a couple of clients acting coherently, by either changing local data (data poisoning) or their individual updates (model poisoning and Byzantine attack). The details are as follows:
- Byzantine attack:
- The aim of this kind of attack is to stop the global model from converging.
- The attack can happen even from an honest client with defective updates, originated from either software bugs or error in communication.
- The attack can also happen from a single or a group of malicious clients.
- How to do the attack? During the model convergence, the updates from all the clients should be small and hence malicious client(s) can estimate with high accuracy the sum of the updates of the rest of the clients from a previous round, just by subtracting its own update from the global model. This allows the malicious client to completely substitute the global model (up to some error) by creating a special local update () that nullifies the rest of clients’ updates while boosting its own update by a factor of .
- Model poisoning / Data poisoning:
- The main goal of model poisoning attack is to cause the global model to misclassify a single adversary-chosen input example with high confidence.
- Model poisoning want the global model to converge, quite different from Byzantine attack which does not want the global model to converge.
- The attack can be done by a single or a group of malicious clients. It appears that model poisoning attacks are typically done by malicious client(s), hence human intervention is probably responsible.
- How to do the attack?
- Model poisoning and data poisoning are kind of intertwined adversarial attack. The model poisoning attack happens by first containing part of the malicious client(s)’ data with adversary-chosen wrong data points. In case of categorical datasets (say MNIST handwritten digital dataset), the original dataset is contaminated with some wrong classification about classifying ‘4’ as ‘7’ where rest of classes are kept intact. This is also an example of data poisoning attack or backdoor attack.
- The idea behind model poisoning attack is to boost the malicious client(s)’ update (kind of similar in concept of Byzantine attack) either by estimating global update with confidence (explicit boosting attack) or adding more loss terms to the learning target to maintain acceptable levels of accuracy (stealthy boosting attack).
- Therefore, in terms of complexity and implementation, Byzantine attack is the easiest to carry compared to the model poisoning attacks.
- Impacts of the above attacks:
- A single malicious client is rather restricted as dataset is assumed to be i.i.d. hence the impact from a single malicious client, either Byzantine or Model poisoning, is not very effective. While a group of malicious clients can have severe impact on the global model.
- Byzantine attack is less severe than model poisoning attack and if done by a single or small group of client(s) can be detected and prevented.
- In model poisoning attack, stealthy boosting attack is often invisible as the update from malicious client(s) are carefully crafted using the total updates from other benign clients. Hence it is more severe than any other above-mentioned attacks.
- In decreasing order of severity, Model poisoning (stealthy boosting attack), Model poisoning (explicit boosting attack), Byzantine attack if same number of malicious client(s) are participating in each attack.
4.0.2 Chosen data for modelling
- For modelling purpose, we will be using either FEMNIST (image classification) or Synthetic Dataset (classification) from leaf dataset.
4.0.3 Defence mechanism against the chosen adversarial attacks:
Countermeasures | Mechanism | Result of countermeasures | Cost of countermeasures |
Large number of epochs
| ——- | —– | Low |
Detection of malicious clients via update statistics
| Get the centroid of the set of local updates and detect the outlier by using either Tukey outlier detection or Kullback-Leibler divergence metric. | List of possible attackers | Medium |
Krum aggregation method
|
| Robust aggregate | Low |
Coordinate-wise median
|
Where returns the median for every coordinate. | Robust aggregate | Medium |
Coordinate-wise trimmed mean
|
| Robust aggregate | Medium |
- There are other couple of simple measures like increasing the number of clients or detection of malicious clients via model metrics which requires a test data set. In most cases, obtaining a test data set from clients is not possible, hence we are not considering the opportunity.
- From literature survey, all the robust aggregation methos work best compared to the method involving update statistics.
- In all robust aggregation, Krum generally works best even in presence of a high number of malicious clients.
Fig 1. The design template of adversarial attack on FL architecture and the defence mechanism.
4.0.4 Experimentation design:
- As mentioned, the FL architecture design is strictly server-client based. No hierarchical structure has been considered.
- We will distribute the chosen dataset into 5 to 7 different clients, and we will assume that (1) first scenario: only 1 malicious client (2) 2 (in case of 5 initial clients) or 3 (in case of 7 initial clients) are conducting the attacks simultaneously.
- Flower python package will be used for the FL architectural development.
- Attack scenario 1: Data poisoning and Model poisoning:
- Data poisoning: We will first poison the dataset in the chosen malicious client(s) by changing one chosen label into a wrong label (e.g., handwritten data ‘4’ wrongly labelled as ‘7’ in case of MNIST dataset).
- Model poisoning: Then we will use the poisoned dataset to get the local updates from the malicious client(s) and use those updates for model poisoning attacks which will force the global model to predict the wrong label with high accuracy.
- Attack scenario 2: Byzantine attacks: The chosen malicious client(s) will simply multiply the local updates by a range of chosen values in an order to stop the global model to converge.
- Defence mechanism:
- In FL setting, the aggregation of local updates happens in the central server. As a defence mechanism, the central server will put a countermeasure, either in the form of Krum aggregation or outlier detection, in order to stop the malicious client(s)’ local updates getting considered into the global update.
4.0.5 Defence mechanism performance metrics:
- In order to see how the defence mechanism in working against malicious client, we first let the attack to happen, and the model will not converge (in case of Byzantine attack), and model will predict the wrong label with high accuracy (model poisoning attack). In classification case, we can follow the evolution of global model accuracy with training epochs (1) considering all the categorical labels (2) considering only the targeted label.
- Without the defence mechanism in place, the global model accuracy should in case (1) be lower than the borderline case (centralized ML solution without FL). In case (2) it should be same as global model with wrong prediction but the percentage of wrong prediction (‘4’ as ‘7’) should be very high.
- With the defence mechanism in place, accuracy in both the cases should be very high, comparable with the borderline case and percentage of wrong prediction should go down to low values with increasing number of training epochs.
5.0 References:
https://www.sciencedirect.com/science/article/pii/S095219762100316X
https://proceedings.mlr.press/v97/bhagoji19a.html
Leaf dataset: https://leaf.cmu.edu/
Flower package: https://flower.dev/
Results of Framework Implementation – Adversarial Fortification
Assumptions of the framework
Assumptions of the attacking framework are:
- The server is honest which means it is not trying to extract clients’ private and sensitive information (privacy attack) neither it is trying to manipulate the global model ‘s parameters in order to change the accuracy of the model or predict wrongly.
- The server has some hold-out test data set which has the exact similar data structure and statistics as the clients’ dataset.
- The data of the clients are identically and independently distributed (i.i.d). This makes it easier to discriminate between benign and possibly malicious clients.
- The malicious client can work alone or can form with a group of other malicious clients in order to conduct a joint attack on server.
- The malicious client(s) is not trying to conduct a privacy attack on other clients or on the server, which means it is not trying to extract private and sensitive information from other clients or from the server.
2.0 Adversarial attack strategies
We have considered :
- Data poisoning attack: Malicious client(s) are poisoning their own private dataset in order to force the global model predict wrongly on the chosen targets.
- Byzantine attack: Malicious client(s) are boosting their own local updates by some large factor in order to stop the global model from converging.
- Model poisoning: This kind of attack is a combination of data poisoning attack and Byzantine attack which means that the malicious client(s) are poisoning the data and then boosting their local updates, trained on the wrong dataset in order to force the global model predict wrongly on the chosen targets.
- Note that there are different ways to do model poisoning attack where the malicious clients carefully craft their boosting factors after estimating the other benign clients update. These types of attacks are way more sophisticated and can do more harm than Byzantine attack. The more sophisticated the estimation is, the more difficult is to put a defence against it. But the goals of the model poisoning attack remain to-fold, either to stop the global model to converge or force it to predict wrong. Hence, we have selected Byzantine and Model poisoning (described above) attack, simple to implement in short time frame but exemplary of both the goals.
3.0 Chosen data and model for FL training:
1. Data:
- Our experiments use the MNIST handwritten digits data set with number of labels is 10, digit 0 to digit 9. This is a classification problem, means the global model, after training, will predict the label correctly from the digit image.
- Out initial choice was FMNIST which consists total 62 classes/labels (10 digits, 26 upper classes, 26 lower classes) and more data points compared to MNIST. Due to presence of a large number of labels, data poisoning attack targeting one or two labels by single malicious clients will have negligible affect on the global model. Hence, we have chosen MNIST in order to show a relatively prominent attack with less computational effort.
2. Model:
- The base global model is a neural network where all convolutional layers are using dense the ReLU activation function, while the output result is using softmax. The loss function is categorical cross-entropy. The architecture is loosely based on Ref [1] and Ref [5].
3. Future direction:
- The federated version of the base scenario uses the same architecture and parameters. The data set is evenly distributed among 5 clients. For the purposes of Phase 1, a small number of clients were selected to keep our experiments tractable. However, in industrial applications, one would naturally expect larger numbers of devices, e.g. O(100)-O(1000). We will attempt to replicate the experiments on larger number of devices in Phase 2, if successful.
- With both small number of clients and a small dataset with 10 labels, it is relatively more straightforward to assess the sensitivity of the FL to adversarial attacks and corresponding mitigation algorithms.
4.0 Metrics for adversarial attack
In order to see how effective on the attacks are, we can use the following metrics:
- Loss function: Loss function is the function we want to minimize for the global model to converge. In the normal scenario which means no malicious client, the loss function should converge to a very small number after some number of epochs. This is also a measure of how chaotic the system is even after convergence.
- Accuracy metrics: As the problem in hand is classification, accuracy metrics can be considered as an evaluation metrics for the FL version as well. In the presence of attack from the malicious client(s) the accuracy of the FL model should be worse compared to the normal situation with no malicious client(s).
- Fraction of wrongly predicted label: As the intention of data poisoning attack is to force the global model to predict wrongly, we should track the fraction of wrongly predicted label on the hold-out test data set at the server side. This hold out test data set is not infected with wrong labels. Hence the fraction of wrongly predicted label on this data set will signal how much the global model is influenced by the malicious attack.
- Note that, loss and accuracy metrics can be calculated both at client(s)’ side (using local model parameters on the private data set) and at the server’s side (using global aggregated model parameters on the test data set). Client(s)’ side calculations are termed as ‘distributed’ while server’s side calculations are termed as ‘centralized’.
5.0 Data Poisoning (DP) attack
5.0.1 Mechanism of DP
- A malicious client wants the global model to wrongly predict ‘4′ as ‘7’ (say). In order to do that it will conduct a data poisoning attack on its own set by reducing the actual ‘7’ label by 80 percent while converting 80 percent of actual ‘4’ to ‘7’.
- Note that after this data poisoning attack, the data set of the malicious client will have unbalanced labels (more data point on label ‘7’ and less on label ‘4’). This will indirectly affect the overall accuracy.
- A malicious client and more than one malicious client can join hand together to conduct similar attack with the same target.
- The malicious client(s) will train their local model with the infected data set and will send that local model updates to the server in order to poison the global model.
- The server, without any defence mechanism in place, will take the malicious local update into the global aggregation and thus the global model will be infected too.
5.0.2 Parameters considered for DP attack.
- Number of clients (CL): 5
- Number of malicious clients (mCL): [1, 2, 3]
- Fraction of data poisoning (frac): 80%
- Targeted label considered: {‘actual label’: ‘wrongly labelled’}: {‘4’: ‘7’, ‘1’: ‘5’}
- Number of local epochs at client(s)’ side for training round: 10
- Number of global epochs at the server’s side for training round: 25
- Number of clients participating at each training round: 100%
- Number of clients participating at each evaluation round meaning sending accuracy, loss to server after evaluating on the local dataset: 100%
- Optimizer: Adam with learning rate: 1e-4. FL server is using FedAvg to get the aggregated local model parameters to get the global parameters.
- Initialization of FL parameters: By default, initializes the global model by asking one random client for the initial parameters. In order to achieve more control over parameter initialization, FL server allows to directly pass the initial parameters to the strategy.
- Loss_centralized, Accuracy_centralized: Loss, accuracy calculated at the server side using the aggregated global model parameters and the hold out test dataset.
- Loss_distributed, Accuracy_distributed: Aggregated loss, accuracy calculated at the server side using the local loss, accuracy sent by the local clients evaluated independently at their side using the private dataset and local model parameters.
- Frac of wrongly predicted label: Fraction of wrongly predicted labels (means actual ‘4’, ‘1’ as ‘7’, ‘5’. This is done at the server’s side using the aggregated global model parameters on the hold out data set. This will indicate how much the global model has poisoned by the DP attack.
Fig 1. Top: Loss (both centralized and distributed) without the DP attack and with the DP attack for malicious client(s) = 1,2,3 with the same frac of 80%. Middle: Accuracy metrics in the same settings. Bottom: Fraction of wrong predicted label at the server side.
5.0.3 Take home points from DP attack.
- DP from 3 malicious clients (>50%) on the targeted labels appear to be most detrimental to model performance, model accuracy dropped down 0.875 to 0.98 while model loss increases to 0.014 from 0.002 making the system more chaotic.
- A single malicious client has limited effect the overall accuracy of the global aggregated model but can affect the local accuracy of the other benign clients (0.93 from 0.988).
6.0 Byzantine (BY) attack
6.0.1 Mechanism of BY
- The main objective of the malicious client is to stop the global model from converging by boosting their own update by a factor, called Byzantine Factor.
- From literature survey, Byzantine attack from a single malicious client can be diminished by some number of epochs.
6.0.2 Parameters for the BY attack
- Number of clients (CL): 5
- Number of malicious clients (mCL): [1, 2, 3]
- Byzantine Factor (BF): [5, 20, 50]
- All the other factors like number of local/ global epochs are same as the DP attack only there are no data poisoning meaning the local models are getting trained on the original data set.
6.0.3 Take home points from BY attack
- One malicious client even with very high BF factor has very limited effect on the centralized accuracy metrics. While DP attack did affect the accuracy of the other benign clients by a relatively large margin, BY with high boosting factor (50) has limited effect on the accuracy of other benign clients by relatively very small margin (0.981 from 0.988).
- When more than one malicious client is joining hands and boosting their own updates by a large margin, the affect on model performance, both loss and accuracy are less severe than one single malicious client. It is possible that the boosting from different clients is somehow managing to cancel each other, not perturbing the global model as much compared to a single malicious client.
- In future, we want to explore further the main reason behind this kind of scenario.
Fig 2. Top: Accuracy metrics for a single malicious client with varying Byzantine factor (BF) from 5 to 50. Clearly this kind of attack even with very high BF factor cannot do much harm to the overall accuracy. Bottom: Accuracy metrics with the same BF factor (50) but with varying number of malicious clients.
7.0 DP + BY attack
7.0.1 Mechanism of DP + BY attack
- Malicious client is poisoning their own private data by wrongly labelled some of the actual labels (DP attack). The same client is training their local model on this poisoned dataset and then boosting its own update by a large factor (BY attack).
Fig 3. Top: Loss (both centralized and distributed) for 3 malicious clients conducting DP attack (with frac 80%), conducting BY attack (with BF 50) and conducting BY+DP attack (frac 80% and BF 50). Middle: Accuracy metrics in the same scenarios. Bottom: Fraction of wrongly predicted labels in case of DP and DP+BY attack.
7.0.2 Parameters for the DP + BY attack
- No of malicious clients: 3
- Fraction of data poisoning (frac): 80%
- Byzantine Factor (BF): 50
- Other parameters are the same as DP attack.
- For comparison purposes, in order to see whether DP, BY or DP+BY together affecting the global model the most.
7.0.3 Take home points from comparison analysis
- DP + BY attack is affecting the distributed accuracy metrics the same way as DP as we already established that BY attack alone with 3 malicious clients cannot affect the global model severely.
- DP + BY attack is affecting the global model to predict the wrong label slightly more than the DP attack.
8.0 Defence mechanism
8.0.1 Different defence mechanism considered
From the above analysis, the most effective attack strategy is DP + BY attack with 3 malicious clients jointly working together by poisoning their own private data by 80 percent and boosting their own update by 50.
During the attack, the FL server was using FedAvg to get the aggregated global parameters. This kind of averaging method takes accounts of all the clients, including malicious client(s)’ local model parameters in order to update the global model parameters. Clearly the malicious client(s) are using this method in order to poison the global model parameters.
We have used other averaging methods in order to see how other aggregating methods are putting a defence against the adversarial attacks.
- FedMed: In stead of averaging the local model parameters for global parameters, using median for the aggregation. As median is less affected by outlier case, theoretically FedMed should put a defence against the malicious attack.
- FedTrimmedAvg: Ordering the local parameters updates for all clients and then trimmed a fraction of smallest and largest contribution (using the parameter beta, ranges from 0 to 1) and take the average of the remaining. During the Byzantine attack and Model poisoning attack, the local parameter updates from the malicious clients are boosted by a large amount in order to supress the updates from other benign clients. So, trimming the largest local parameters will potentially trim out malicious clients’ updates from aggregation.
Fig 4. Loss and accuracy metrics against different aggregation methods like FedMedian, FedAvg and FedTrimmedAvg with trimmed factor beta = 0.4, 0.2, 0.15 and 0.05. Loss and accuracy metrics are more affected by adversarial attacks while using median instead of average during aggregation. So far, FedTrimedAvg with beta <=0.15 is providing the best accuracy compared to others.
Fig 5. Left: Fraction of wrongly predicted label in presence of different aggregation methods. FedMedian and FedTrimmedAvg with beta=0.4 are severely affected by the adversarial attack compared to others. Right: FedTrimmedAvg with beta=0.05 is providing the best defence against the attack by reducing the fraction of wrongly predicted label close to minimum.
8.0.2 Take home points from defence mechanism
- Note that we have considered a strong adversarial attack where more than 50 % of the clients are working together to force the global model predict wrongly. FedAvg is putting so far, a strong defence against this attack by keeping the fraction of wrongly predicted labels to a very low value 0.017.
- FedMedian is getting severely affected by this adversarial attack as number of malicious clients are more than 50% hence median value chosen by FedMedian is probably updates from the malicious clients. FedMedian should perform better if the number of clients is larger. It will be interesting to explore further in that direction.
- FedTrimmedAvg with beta <=0.15 is putting more defence than FedAvg. As beta values are very low, it is successfully trimming the boosted updates from the malicious clients. While beta = 0.4 are trimming updates from both benign and malicious clients, hence it is getting most affected by adversarial attack.
- The defence mechanism is strongly related with the number of clients and fraction of malicious clients.
- So far, we have considered only different robust aggregation for defence purposes where the whole purpose is to neglect the updates from the malicious clients. There are other methods like outlier detection using model metrics (using the hold out test data set) or update statistics which can estimate number of malicious clients or a list of them, if possible. It will be interesting to implement those defence mechanism in future.
9.0 Summary and outlook
- We have considered MNIST dataset (10 labels) and 5 clients. Data poisoning attack from a single malicious client targeting two labels is sufficient to reduce the overall model accuracy of the other benign clients to a relatively small but noticeable margin. Among data poisoning (DP) and Byzantine attack (BY), DP has more affect on the adversarial attack compared to BY.
- As explained earlier, with small number of clients and with only 10 labels, it is relatively more straightforward to assess the sensitivity of the FL to adversarial attacks and corresponding mitigation algorithms. Situation will be different with a greater number of labels where malicious clients must target more than 2 labels in order to get a substantial adversarial attack. Similarly, adversarial attack from a single malicious client, even carefully crafted will have much lesser impact with increasing number of clients. Situation will drastically change if there are joint malicious attack from a significant number of clients targeting more labels. We want to explore the situation in future with a larger client sets and more targeted labels.
- Defence mechanism is strongly dependent on the number of clients and fraction of malicious clients. In our case, FedTrimmedAvg with low beta values (<=0.15) is putting the best defence against a very strong adversarial attack (3 clients jointly).
- It will be interesting to explore how both adversarial attack and defence mechanism change with increasing number of clients and dataset with more labels.
10. References
[1] Review paper on Security and Privacy: https://www.sciencedirect.com/science/article/pii/S095219762100316X
[2] Byzantine Attack: https://papers.nips.cc/paper_files/paper/2017/file/f4b9ec30ad9f68f89b29639786cb62ef-Paper.pdf
[4] Backdoor FL: https://arxiv.org/pdf/1911.07963.pdf
[5] PyTorch CNN with MNIST data set: https://medium.com/@nutanbhogendrasharma/pytorch-convolutional-neural-network-with-mnist-dataset-4e8a4265e118