 I'd like to say thanks again for coming and good afternoon. My name is Joseph Clements, and I'm here to present my recent work published in the paper, Hardware Trojan Impact on Neural Networks. So I am a PhD student from Clemson University at Clemson University at Clemson University. I work closely with my PhD advisor, Dr. Ndla, and our research group, Secure and Innovative Computing Research Group. My specific areas of focus are adversarial machine learning and hardware security. We also have members of our team who work on VLSI design and approximate computing, as well as post-quantum cryptography and homomorphic computing. Today, I'd like to begin my presentation by building a motivation for hardware security and machine learning, and then by describing the landscape of hardware attacks in hardware attacks. And then after that, I'll present our attack as one example of an attack possible on machine learning in the hardware domain. After that, I'll finally conclude the paper with future directions in this field. So the modern paradigm on machine learning is to implement machine learning in the cloud. In this system, a designer will first import data to the cloud, train that model on the cloud, and that model is then housed on the cloud. And whenever an edge user wants to infer with that model, the user will export his data to the cloud, and then the machine learning will happen on the cloud, and then the inference is sent backwards, and then the inference is sent back to the edge user. Systems like this are electronic assistants that we all know of. Facial recognitions used by social media and security applications, such as email spam and malware prevention. After sales scenarios in this setting have been well studied, there are two avenues of attacks that people can take when attacking machine learning in the cloud. They can take attacks in the training phase, which attempts to modify the training phase so that a malicious version of a machine learning model is created. Adversaries can also implement attacks in the inference phase in which they try to take a model that's already been built and find a way to maliciously produce outputs within. Again, adversarial machine learning in this scenario has been well studied. However, we still need a lot of future research in this area. Unfortunately, however, machine learning in the cloud is not suitable for every scenario. For example, because of the latency issues with communicating back and forth between an edge user and a cloud user, systems like automatic driving, which need real time inference, are not suitable due to latency issues. Similarly, security systems may have security flaws due to latency issues. In mobile applications and wearable technologies, where machine learning is really becoming big, users tend to be very needy in that they want their machine learning applications to work well regardless of whether they have stable connections. And in a lot of cases, this is not the case with cloud-based machine learning. And therefore, we predict that machine learning will at least in part move to the edge. And in this system, the training still occurs in the cloud-based system. However, the inference is moved from the edge to the cloud. And the way this is done is that the global model that is stored to the cloud is reproduced on all the edge devices so that the edge users can now communicate directly to the machine learning model on their own device. While this gets rid of issues like latency and communication issues, this, however, adds two additional constraints to our models. One that edge devices are often very computationally have a lot of computational limitations in comparison with cloud computing systems. And also, they often run off battery powers and so are very limited in their power restrictions. Because of this, we see that because of this, we will now have a need for machine learning to have very diverse hardware platforms to be able to handle these power consuming large, large, deeper and deeper neural networks in edge-based systems. We'll also have a need for software and hardware optimization. Because of this, the supply chain becomes very important when we're talking about an edge-based system. The security system, sorry, the adversarial machine learning in this scenario, in some ways remains very similar to adversarial machine learning in the cloud. However, in other ways, they are very different. For example, as trend is still pretty much the same done in the cloud, the training phase will remain relatively the same. However, the inference phase, an adversarial may have direct access to the physical implementation of the machine learning algorithm through the edge devices. And so it attacks in the inference phase may be much easier now than there were in cloud computing scenarios. In addition to this, we also have a new avenue of attack for adversarial in that they can attack the production phase to target the machine learning implementation. Unfortunately, the modern Fabulous business model has a lot of security holes. This model of supply chain is very economic. In the past, the supply chain was horizontal and where one company would do most of the steps from circuit design to fabrication to manufacturing. However, in the horizontal or Fabulous business model, the steps are divided up into multiple companies, sometimes spanning multiple countries. And therefore, there are three key issues in the Fabulous business model. One, that third-party IPs are very common. Three, that globalization is very common. And four, that there are generally multiple vendors in these systems. However, these three things contribute to devices in Fabulous business models being untrusted. Therefore, the attacks in the hardware domain have been very extensively studied as well. We're going to talk about four different attacks in the hardware domain. One is IP privacy attacks, counterfeiting attacks, supply-channel attacks, and hardware-driven attacks. So IP piracy is when an adversary attempts to steal the intellectual property of another person and attempts to pass it off as their own. IP attacks or IP piracy is seen in software as well. However, it is sometimes arguably easier to do in the hardware due to the fact that if an adversary has direct physical access to the hardware, they can simply reconstruct the device and look at it in the microscope, and they can rebuild it from physically looking at it. If they have access to a supply chain, we then have a problem of IC overbuilding where an entity can simply reproduce more devices than they're allowed to produce. And they have essentially created multiple copies of the IP that they can now use. Because of the economic costs in producing IPs, such as paying engineers and development costs and research costs, gaining access to IPs in this way can be very economic, especially if they have easy access to the physical device or the supply chain. Counterfeiting is the flip side of this. Counterfeit is when an entity takes an item and tries to reproduce it and make it seem like it's someone else's. For example, we've got over here two pictures of a fake iPhone and a real iPhone here, a fake Arduino and a real Arduino. And so you can see that sometimes these counterfeits can be very similar. And again, these attacks have been seen in hardware and software. However, sometimes these attacks can be very easy in the software due to an adversarial physical access to a device and for physical access to the supply chain. In fact, it's been studied that up to 63% of all parts flagged as counterfeits are integrated circuits. The research that published this says that it might actually be higher due to the problems with detecting and proving that counterfeits are counterfeits. The other issue with counterfeits is that because they're often made with reverse engineering, they can be modified very easily and house malicious functionality that was not present in the original device. The third side channel attacks cannot be done through the supply chain like the two previous attacks. This one has to be done through access to the physical device. A side channel attack attempts to use leaked side channel information from the device in order to gain some knowledge of the functionality or hidden knowledge on that device. Classic example of a side channel attack is side channel attacks on ABS algorithms. This encryption system was thought to be computationally secure post pre-quantum computing. However, it's been seen in the literature that through side channel attacks, which take advantage of hardware implementation weaknesses rather than algorithmic weaknesses, these attacks become relatively easy through side channel attacks. The final type of attack we have today are hardware trojans. A hardware trojan is when an adversary attains to maliciously modify a circuit design such that the functionality changes. These attacks have also been seen in software. However, they're also very easy to do in hardware, especially if you have access to the supply chain. Unfortunately, these attacks cannot be done through physical access. They need access to the supply chain. One key issue with hardware trojans is that they are persistent in that once a hardware trojan is in a hardware device, you cannot remove it. You essentially have to scrap the device and it can't be used anymore. So hardware trojans have been studied a lot in hardware security. The reason being because they're so dangerous, a lot of different classification techniques have arisen. So there are many different ways to design hardware trojans. Hardware trojans are broken up into two basic components. The first being a trigger, the second the payload. The trigger is what activates the hardware trojan. The trigger searches for some rare internal condition inside of a circuit and then activates the trojans payload. The trojans payload is the component of the trojan which is going to perform the malicious modification needed. There are two key issues that attackers need to think about when developing hardware trojans. One is their stealth, which is very closely tied to the trigger design. And the second is the effectiveness, which is very closely tied to the payload. So in designing the hardware trojan, balancing these two key components is non-trivial. So our specific tap is a hardware trojan to tap on neural networks. Software trojan attacks on neural networks have already been seen. These are done by creating a key input trigger, which can be applied to an input to the neural network. And then using this key input, training data is created, which is similar to the original data. And then the network is then retrained. Specific parameters of the network are retrained to produce the software trojan. In our case, we have the same goal. We want to insert a stealthy backdoor into a neural network classifier, which forces a malicious output classification whenever a trigger is present. However, there are four main differences that come with power attack. One is that it is implemented in the production phase. So it has to be done in the supply chain. It can't be done afterwards or during the train phase. It's implemented in the production phase. The second is that it targets the network's operations rather than its weights. So for example, in a trojan attack, you would insert a trojan into maybe a multiplier or the components performing the activation function and apply your modifications to the hardware that way. Second is that it inherits some properties from hardware trojans in that it is persistent and that it is very difficult to detect and defend against. And finally, it doesn't involve any retrain. And so none of the weights are modified at all during our attack. It is simply the hardware implementation that we're modifying. Our attack is done in four separate stages. And I'm going to talk about this on a rather high level rather than get it to details. However, the way we start this is to select a target layer. And then inside of that target layer, we select specific operations, such as the multiplier that adds the activation functions. And we isolate this target operation. And in our case for ease of discussion later, we simulate breaking the network up into two different neural networks. The first sub-neural network is the function implementation from the input layer to the output of the target operation. The second sub-network is the network from the output of the target operation to the primary output of the neural network. Once we have the target layer, we can then select the input trigger key. There are two different ways we can select input trigger keys. As you see here, we have a low-form input trigger, which looks exactly like in this data set, wood. However, we can also choose randomized input trigger keys, which would just be a random value. These input triggers have to follow the actual physical. They have to follow the physical constraints that could actually be applied to this input key. Once we have the selected trigger key, we then feed that to the first sub-neural network that we've created. And we look at the internal activations at each of the nodes of our neural network. We call these intermediate activations intermediate values. And we specifically look at this final intermediate value, which is the output of the target operations. When we have this output, we can then move on to the third step. The third step is to determine the operational perturbation to be applied to the target operation. We take that intermediate value that corresponds to the target operations value and the second sub-neural network. And we modify a version of the up and adversarial example attack. The modified version of the adversarial example attack, rather than altering the parameters of the neural network, sorry, altering the input of the neural network, alters the output from that target operation. We have a very specific goal when we're doing this in that we want to limit the amount of perturbations that we're looking at here. Because we want the hardware implementation to be as small as possible. And after that, we then compile everything back together by taking the targeted operations and modifying the ones we need. Notice that because of our choice of adversarial perturbation, which limits the perturbations, in most cases, we only need a small subset of the neurons to be modified. The way that these neurons would be modified can potentially use any hardware to design such as the ones we've seen before. For example, we could place a Trojan inside of a multiplier, which modifies the operation of the multiplier to be a modified version of the multiplier. If we were looking at an activation function, we could determine two different activation functions, one corresponding to the malicious modification, one corresponding to the benign modification. We could then create a trigger, which searches for a rarely occurring internal activation at the input of that activation function. And then if that occurs, we'll then switch the output from the benign version to the malicious version. To demonstrate our attack, we set up four different experiments. We, in two of the experiments, we used well-crafted triggers for the experiments. We used well-crafted triggers. And for other experiments, we used randomized triggers. For each of those cases, when we attack the randomized trigger, since the outcomes of the randomized triggers are essentially already untargeted, we had to use target attacks for the adversarial example. For the well-crafted trigger, we instead looked at differences between bounding and unbounding the constraints on the attack. So when we evaluated this, we essentially had three different metrics that we looked at when we were doing this. One was the effectiveness of the attack. We considered the effectiveness of the attack to be the amount of input triggers that effectively reached a malicious Trojan modification. We found that, on average, 97% of our attacks worked. We also evaluated the effectiveness under functional testing. Functional testing is when the produced model is compared to a golden model. And so we take a golden model and we pass the testing data from our target data set and we pass that through the machine learning model. And we compare the outputs from the golden model with the outputs from the modified model to compare the two outputs. We saw that 100% of all of our input-output combinations matched between the two different unmarked five-version data model. Finally, we tested for stealthiness under behavioral testing. When you're testing a chip for behavioral testing, you test the side channel effects, such as power consumption, timing properties, and so on. And so these metrics often generally correlate directly to the amount of modifications made to the hardware. And so when we're analyzing the stealthiness under behavioral testing, we look at the percentage of neurons in each layer that is being modified. So in some cases, as little as 0.3% of the neurons in the layers of the modified models. OK, I'm going to read this because it's easier. So as we can see from the experimental results, with access to the device's supply chain, we can perform a stealthy and effective attack on machine learning models by inserting hardware Trojans in the physical implementations. However, this is just one example. As described earlier, there are many other research fields in hardware security and many possible hardware attacks that can be mounted on machine learning devices. In scenarios where an adversarial has physical access to either of the devices running on a machine learning model or its supply chain, meanwhile, we have only talked about inferrence on the edge scenarios. However, new novel machine learning paradigms, such as federated learning, new model, new novel machine learning paradigms, such as federated learning seen here, which attempts to move training, at least partially from the cloud, into the edge devices are also possible. In these scenarios, the training phase may also be subject to attacks through the hardware implementation. Therefore, to ensure the safety of machine learning and paradigms where globalization and physical access are present, the development of systems should be security aware. That's it for my presentation. So are there any questions? Yes.