 Hello. In this session, I will talk about fault injection as an oscilloscope, fault correlation analysis. This is work done by Albert Sproul, Alisa Milburn, and me, Wukasz Khmilewski. This talk concerns both fault injection and side channel analysis. On the left side of this title slide, we can see an oscilloscope, a tool commonly used for fault injection. Here we see that it collects some side channel traces. On the other hand, we have our voltage glitching device that we will effectively use to produce traces that look like side channel traces. And actually, these traces here, this is not power consumption, this is actually a trace constructed using fault injection. Let me give an outline of our presentation first. At the beginning, I will show the problem statement, so how side channel analysis and fault injection coexist, and how possibly we can use side channel analysis techniques to generate new methods for fault injection. Then I will present our main technique. So I will show how we are constructing traces, like side channel traces from faults, and then how we apply the standard side channel techniques. This way we construct simple fault analysis called SFA and correlation for fault analysis CFA. These are the main results of the paper. Additionally, in the paper we consider also collision attacks and linear regression analysis. However, in this presentation, due to time constraints, we will omit it. Subsequently, I will talk about our experimental setup and results from practical experiments. Next, I will compare our results, our techniques to other various fault injection attacks presented in the past, so to relate it work. Finally, I will conclude the presentation. The main message to remember from this presentation, we show how to apply existing side channel attacks in a purely fault injection setting. By translating fault injection results into probability traces, which are analog to standard power or side channel traces. For the details and this presentation is quite brief, so for the details, I refer the listeners to the article. There are two kinds of side channels, passive and active. Passive case is if we essentially use the robot, the device does. It could be done via either power consumption, electromagnetic emanation, time, temperature, light. There are multiple ways, but the main thing is the device behavior stays unaltered. So, for example, we have device performing AES. We measure power consumption during these AES executions. That's all. That's the side channel. Now, the other case that we see on the right, this is fault injection. In this case, it's similar in the sense that we again access the power line of the device, but then we inject direct bleach. So, for example, a dip in the power consumption at very precise moment in time, by that we alter the behavior of the device. It could be done using power, electromagnetic fault injection, or even lasers. The passive case, the attacks in the passive situation are referred as side channel analysis, and in the active case, they are referred as fault injection. What are the similarities and slight differences between these attacks? In general, in side channel analysis, we have many presented attacks that are quite often generic. They can work for various algorithms, some standard techniques. In case of fault injection, there are less publications, and often the attack are tailored to either a very specific cipher, very specific case, or there are some strong assumptions being made about what the attacker can do or not. Now, since there are much more attacks in this side channel attack case, our research question here is, can we apply side channel attacks in the purely fault injection setting? By that, obtaining many, possibly many attacks. This is the question that is answered in this presentation. Let us have a fast look at how a typical attack of fault injection and SCA look like. First, of course, we need to build setup, that's a standard part, then we need to perform a characterization. What does it matter? What does it mean? It means that, for example, if you want to do a side channel analysis on AES, we probably will attack a first round of AES. We don't want to attack all 10 rounds of AES at once. This will take too much time, first round, or even part of first round is enough. There are many ways to do it. One is to look at some characterization traces. The main message here is that we want to concentrate on non-profile approach. We are assuming that we just have a device, we maybe look at the traces, but we don't have a separate device on which we control the key, and we can do some run-barry statistics. Now, we just look at simply how the traces look, and then we perform our attack. We don't want to have this stronger power of profile case, because it's less realistic. Then the second step of the attack is collecting data, collecting data. In case of side channel, we simply, an attacker simply would collect power measurements using passive probes that could be also electromagnetic emanations, etc. In case of glitching, an attacker would use a VC glitcher or an electromagnetic fault detection glitcher, or even a laser to perform fault injection, and collect, for example, safe attacks from AES. Then after the data are collected, the attacker, in case of side channel analysis, can run correlation power analysis or simple power analysis on the side channel traces that were connected. These are some techniques for some statistical techniques to recover the key. In case of fault injection, an attacker can run differential fault analysis on AES to recover the security based on fault deciphered tests that were collected during the previous step. What are the challenges of a classical fault injection attack? First of all, jitter. This is quite practical, but very often in practice, we don't maybe have a perfect trigger for our fault injection attack, or simply the device, the clock of the device jitter, so we don't always perform fault injection exactly at the time you want to perform it. There is randomness, hence there is noise. We need to overcome that problem. The other problem is no access to ciphertext, so sometimes our device performing AES maybe will not return at all ciphertext, and therefore we cannot mount a differential fault analysis attack. Additionally, there is so-called fault injection redundancy counter measure. This is the situation when the AES is performed twice. The result of AES is compared in these two executions. If it's the same, then there is the ciphertext is returned. If it's not the same, it's not. In this case, essentially there would need to be performed two fault injection attacks to succeed, and they would have to be done in the same way. That's not easy. In our work, we take these two challenges into account when we design our solution. We try to overcome both jitter and fault detection counter measures. How do we construct our probability traces from faults? Already more than 10 years ago, it was noted that the fault probability is dependent on the data being processed by a device. Additionally, of course, this is true, but operation leakage would be also visible. It's even much stronger because it means that different operations are being performed at the chip, so we expect that the fault probability would also depend on different operations that will be shown later on. What we do is we transform our voltage fault injection device into a single bit sampling oscilloscope, and from this result, from the single bits, we construct our probability traces. Let us have a look at the bottom at the power consumption trace of first round of AES on one of our targets. This is simply one AES power trace. Can we build something similar with fault injection? Yes, we can. We have here such a trace. What do we do? We go to the time offset just after trigger, and we run 15,000 times fault injection at this point in time. Then we construct a bar chart here, so we measure how many successful fault injections we assume, and then we move minimally more in time. Again, we do 15,000 fault injection times against 15,000 fault injections, and we continue like that till the end of the trace. We maybe performed a lot of fault injection tries, but we see that we effectively constructed trace similar to the power trace. This trace could be used, for example, for characterization. How do we do data collection? First of all, we need to decide where we want to glitch, and second, we need to decide what glitching power do we use. We decided to use a very non-profile approach for especially glitching power. We simply glitch with very wide parameters of power, and then for our experiments, we choose the power around when we achieve 50% of mute. When the device stops answering 50%, that's the moment where that's more or less the center of our power that we used, and then we only randomize it slightly around that value. How do we recognize successful fault injections to build our crisis? We use two approaches. One is called mute approach, and the second one is access probability. Let us talk first about access probability because that's coming from related work. This is simply an information whether the ciphertext produced by ADS that is running on our device is correct or not. If it's incorrect, then we assume this was successful fault injection, that's what we used to produce our trace, and otherwise it was not successful fault injection. It was correct execution. Now, in case of mute, that's more than introduced by us. In this case, we just assumed that the device doesn't answer or recess. The fault injection really stopped the device from executing. From executing the AES for returning the result. I will explain later how we use it to achieve successful attack. What also is important to consider is in this model, for each plain text, we apply multiple fault injections at the same point in time and then mute to repeat for different points in time. This way, we obtain an estimate on the probability of a fault occurring. That's how it would be in the ideal case. On the next slide, I will explain how we do it slightly differently to perform less fault injections. The number of points of fault injection is essentially like a desired resolution of our probability trace. Similarly, like inside analysis, and the number of fault injections at the specific point gives us the precision of our measurements. Let us talk first about the concerns in trace constructions. As mentioned before, there could be G-turn noise. The domain can be very sparse, then it would cost that we need a lot of fault injections. Another issue, since PLS are often enabled in practical targets, the G-turn may occur not only to the trigger issues, but it also could occur due to simply the clock being not completely stable to various effects. Furthermore, we don't really analyze the software that is running on our targets. We use more black box, fire and forget approach, also for practical reason because the attackers often don't really know what software is running on their device. To overcome the above concerns, the above problems we perform, the trace constructions slightly differently than in the ideal case described on the previous slide. First, we use the bucketing of the results. It corresponds to the oversampling in the side channel analysis case. We divide the attack window that we chose, for example, first round of AES into buckets of equal duration and calculate combined fault probability for that bucket. What might be a problem with that approach, with that point alone, would be that there could be aliasing. So essentially we need to apply sort of a low pass to this situation. So this would be a problem if, for example, leakage would happen just on the edge of two different buckets. Therefore, we simply overlap buckets that looks a bit like low pass in case of side channel analysis and that's our method. After we have the traces, we can perform in quotes any side channel attack. We will show two attacks. We believe many other attacks can be also performed, but most likely not any. Let me talk about our experimental setup. We have our PC. PC communicates via serial communication with our targets. It also instructs via USB our glitching device that provides power to the target and can cause glitches. How our glitcher is being triggered, it's triggered by the last byte of the serial communication being sent from PC to the target. Sometimes in few experiments we also use target directly generating the trigger here to the device to call the glitch, but usually we use the communication. We consider three different software targets. So these are AESs, so these are AESs or RSA running on an AVR, 32-bit ARM or RISC or VCPUs. And we also perform a proof of concept analysis on XMega hardware AES engine. Our setup is low cost. It costs less than 50 dollars, even together with targets, I believe. The description of that is on the following link if someone is interested and the picture of that setup is of a similar setup is shown here. This is a picture from that website. Let us have a look at simple fault analysis that is based on simple power analysis on RSA. Here we have such a characterization trace, similar to before, constructed in the way described in previous slides. This is just a square and multiply implementation of RSA and we can, I hope we can see that the patterns here are different. In case of light green patterns, they correspond already to processing of zeros and the dark blue patterns corresponds to ones. This is simple fault analysis. What we also done subsequently is fault correlation analysis on different implementations of AES on different architectures. On the top we see analysis on RISC-V of straightforward AES implementation. In case of mutes, we need around 30, 35 million fault injection attempts. In case of the success case, so when we know whether CypherTex was correct or not, we need around 20 million traces. Similarly for ARM architecture, we need 80 million traces and slightly less in case of when we know whether CypherTex was correct or not. What we can notice in this picture is that actually mutes require slightly more traces, but clearly the key can also be recovered. What's also important to mention, but that's more emphasized in the paper, is if we would know a bit better where we need to include the fault to generate, to recover the key, to break the key. Then the number of fault injection attempts goes between 5 and 30 times down depending on the architecture that we attack. Now let us have a look at the rest of our experiments. We attack here an optimized implementation for ARM. Again, we are able to recover the key. And similarly, the hardest case was for XMega. For XMega straightforward AES implementation in the success model, we actually can recover the key with 16 million traces. However, in case of the mutes approach, we see that there is much, much, much more noise. The situation is much more harder, but we still see clear entropy reduction in the key. Our last experiment was about attacking XMega hardware AES. In this case, the hardware AES engine runs in a separate crypto engine, and then there is also the main chip, the main processor. This attack on this target was done more than 10 years ago by Ile Kizvatov. He described in the paper the model that was used and he was acting the leakage model that he used in such an analysis, and he was able to recover all 16 bytes. In our case, however, we used the same model, we used fault injection approach, but we noticed that it can recover only three bytes completely, and the other bytes, we don't see leakage. What could be the reason of that? We believe that the reason for that is that we set our glitching parameters to glitch effectively the software, the CPU. We didn't try to glitch the hardware, we just see whether the device answers or not. Could it be that we are glitching the main CPU? We have looked at the code that is running on main CPU during the execution of hardware AES. We noticed that there is a polling loop consisting of five instructions, and it seems that only one of these instructions, when we glitch, affects the results of the hardware AES engine in a substantial way that we can mount the attack. Therefore, intuitively, we can recover only every fifth key byte, and that we can see here that that's probably the case, because that's the only moment in time. Each five instructions we can see, for example, input correlation. Therefore, we can say that this is just proof of concept. It's a partial success. How to solve it? Possibly by using wider range parameters and using much more fault injection parameters, we would be able to see this situation when we would be able to affect them using our fault injection to see this fault sensitivity coming from the hardware AES engine. We believe it's maybe a bit similar to clipping quantization errors in case of such analysis, at least related to analogous. Okay, let us compare various fault injection attacks to our attack. Our attacks are presented in the bottom row. We can see it here. What was, for us, the most important? For us, the most important was to have a generic solution with little assumptions. That, for example, means that we would like to have a technique that allows us to attack various targets. In our case, we were able to attack public and private key, symmetric and asymmetric cryptography, and also hardware AES engine, at least we showed a proof of concept. Many techniques also are applicable to many different crypto primitives, for example, CFA, say, ferro attacks and differential fault analysis. We also wanted a non-profile approach. Therefore, fault template attacks are not the approach that we were interested or to have a similar approach. We also assumed that due to the practical approach, we would like to show results in which we don't have this clock control due to PLS being enabled. Many attacks are shown in this scenario, when the control over target is quite large, and that's hard to achieve in practice sometimes. We also assumed no ciphertext knowledge, so there had been a lot of work when this marked here attacks. They only require cipher correctness information. In our work, we only don't achieve that, but also we add this new detection situation when we only need to know whether the device is muted or not, and that's actually enough to recover the key. All that flexibility comes, unfortunately, the price of a large large amount of faults. There are other aspects discussed in the paper. To conclude, we have presented a generic technique for translating such analysis to fault injection attacks on the example of simple fault analysis based on SPA and correlation fault analysis based on correlation power analysis. We also investigated two different classification assumptions, mutes and successes. We successfully attacked cryptographic libraries, running on three different targets, and we also presented a proof-of-concept against the hardware to the engine. Our priorities was to have generic attacks and practical, and the drawback is a relatively large number of fault injection attempts. These results show that the relationship between fault injection and side channel is strong, and we can run relatively unmodified side channel attacks on the results of fault injection campaigns. Thank you very much for listening.