 So our first talk is a fault attacks made easy differential fault analysis automation on assembly code by Jacob Brie, Jalu Hu, Lang Lui and presented by Jacob Brie. Thank you. So good morning everyone. So this is the outline of my talk. First I will present some general background on fault injection attacks, differential fault analysis and I will present the motivation of automating this. Then I will explain data which stands, then I will present data which stands for DFA automation tool for assembly code, which is the tool which implements the methodology from our work. Then I will present the case study on present cipher which we analyzed by the attack and finally I will come to conclusion. So what are fault injection attacks or fault attacks? So they are semi-invasive physical attacks. For this kind of attack, often a device the packaging is required in order to get the direct access to the chip. These attacks exploit the possibility to insert a fault in the process of the algorithm execution in a way that could help reveal the key. So basically these attacks change the values during the processing of the algorithm. This idea was introduced more than 20 years ago. First, Bonach, Damilo and Lipton targeted CRT version of RSA algorithm. There are several fault injection techniques which can be used. These are probably the most common ones. So we have voltage glitching which varies the supply voltage of the chip to change the values. Similar to this is clock glitching which varies the clock signal of the chip. Then we have electromagnetic fault injection which can be either harmonic one which is a stable pulse which affects analog circuits or pulse injection which affects digital circuits. Then we have lesser fault injection which is probably the most precise one out of these. For this the deep packaging is required in order to have access on the chip. So after we inject the fault we need to do some analysis method in order to recover the secret. For our work we used DFA or differential fault analysis which is the most popular fault analysis technique to target symmetric block savers. It was also introduced more than 20 years ago by Bihem and Shamir. For this attack the attacker injects a fault into the chosen round of the algorithm. Normally it's one of the last three rounds. Then he gets the faulty cipher text and at the end he compares the faulty cipher text with the original one to get the secret key information. Why do we decide to automate this? So far all the current symmetric block ciphers have been shown to be vulnerable against faulty text especially against DFA. So the question is not whether the algorithm is secure or not but which part of it is particularly insecure. And to this question automated methods can provide an answer fast with a minimal need of human intervention which is more error prone. And then why automation assembly code? So in practice the attack always has to be done on a real device so we are not doing it on a high level cipher representation. And different implementations of the same algorithm do not share the same, do not have to share the same vulnerabilities. And also there might be an exploitable spot in the implementation which we can't really see from the cipher design because the implementers use techniques to optimize the algorithm execution. So while there are works which focus on the cipher design level, one of them will be presented by Shia and Iblater, there is no work aiming at the FA on the assembly level to such extent. So we try to bridge this gap by our work. This is the overview, the high level overview of the attack. So the tool takes the assembly code as an input. It constructs customized data flow graph which preserves important aspects of the implementation. So for example what are the ciphertext nodes, key nodes, plaintext nodes and which instructions are nonlinear because these are important for the DFA. And then based on user-specified output criteria, I will talk about this later, it selects vulnerable nodes. For each vulnerable node it creates a sub graph. So the sub graph is basically portion of DFG which captures the fault propagation from the vulnerable node all the way to the ciphertext. And for each of the sub graphs it generates a set of fault analysis equations or DFA equations which can be directly used for the attack. So what are our assumptions? The first one is common for DFA. It assumes known ciphertext model and a single fault adversary. The second one, the single fault adversary means the attacker can inject exactly one fault during the algorithm execution. Then we assume the implementation is known to the attacker which is also a common assumption for DFA. He can also add annotations to assembly code just to specify the rounds, round keys, ciphertext words, et cetera. For our work we have chosen the admin IVR instruction set. However, if you take the whole framework, only the parsing sub-system has to be changed in order to use some different instruction set. The analysis works on the DFG and that part is universal. Also the methodology presented in the paper is universal. And the last assumption is we assume the implementation is unrolled. So there are no direct or indirect jumps. It has been shown before that if we actually have these jumps the attacker can always skip them and then trivial fault analysis can apply. This is a dummy cipher, an example program and corresponding data flow graph generated by DataTek. So we can see that DataTek identifies certain nodes like the key nodes and it analyzes instruction by instruction. So here we have highlighted the anti-instruction which is a nonlinear instruction in this code. So it splits into rounds and when it targets some instruction it takes the fault propagation all the way to the ciphertext. The vulnerable nodes are selected according to output criteria. So what are these? The user can specify, for example, how many ciphertext nodes should be affected by the vulnerable node. Then what is the distance? What is the minimum distance and maximum distance from the vulnerable node to the ciphertext node? So this means what is the number of nonlinear instructions in this path? Then the user can select what is the number of round keys. So this basically specifies up to how many rounds from the last round we will be targeting and what is the number of keywords we want to target by this single vulnerable node. So if you take the previous example, let's say we select the output criteria to be all ones. So just one ciphertext node, the distance is exactly one. The number of keywords is one and also we want only to attack the last round key. And the DataTek selects vulnerable nodes. This is one of the nodes, R0. And the second one, it creates subgraph for this. So there is another important parameter, which is depth. Depth specifies how many layers above the vulnerable node we want to see. This is important when we analyze the equations because sometimes we can't really see the full propagation directly from the node, but we can see it if we go several instructions higher above the node. So on the left side of the picture we can see the depth 0. On the right side there is depth 1, so there is basically one instruction above the vulnerable node. Now if you take the right side picture with the depth 1, DataTek generates the equations which are here. And for this we can already see how to do the DFA. So for example for this case in the first equation we can see that some value is ended with some constant which has four zeros in the beginning. So in case we skip the instruction number 8, in equation number 3, we get directly first four bits of the secret key in the ciphertext because instead of the product of the third equation, actually the product of the second will be used, sorry, the product of the first equation will be used. So the exor will contain four zeros at the beginning. This might see as a simple example, but I will show later that some implementations actually use constants heavily to optimize the code. So just a simple recap of present cipher which we used for case study. It has block length of 64 bits, key length can be either 80 or 128. It is based on substitution permutation network. So it has a key addition, S-box layer with 4-bit S-box and a bitwise permutation. So these three operations are repeated in 31 rounds and then there is a post-wetting key addition at the end. If we construct the data for graph of present, it is very complex and it is very hard to analyze manually. The unloading implementation consists of over 4,700 instruction actually. However, if you use data it only takes a couple of seconds to actually construct the subgraphs and equations for each of the vulnerable nodes. So what we found is an implementation-specific attack on present. So we just took publicly available implementation and unrolled it. Then we selected kind of default output criteria which is all ones. And the attack found can recover the last round key by just 16-fold injections. So far the DFA is on present. Always explore the S-box lookup which requires the analysis of the difference distribution table. However, our attack which is implemented in specific takes the implementation characteristics into account and it exploits the OR operations operation which is used in this implementation. So how does it work? Basically the vulnerability of the implementation is in a way how the S-box layer and the permutation layer are combined into the form of tables. And basically then the output of these tables is always two bits from each table. And we need to combine the outputs of these tables. So for combining the outputs, a series of ORs and ANDs are used together with the usage of some constants. So for example, this is one of the attacks. We can see that some intermediate value is ended with 0, 3, which means the first six bits are zeros. And in this node the R23, if we flip some of the first six bits, we can get the values here because the rest up to the ciphertext is linear. And once we have the first six bits of R22, we can very easily get the first six bits of one of the key nodes. Because the first six bits are linearly related. When we want to recover the other two bits, in this case we need to go higher. So we need to use depth up to 3 to get the equations which actually show us all the other constants where the last two bits are actually zeros. And then we can recover the other portion of the keynote. And in the similar fashion, we can recover all the other key nodes because they are done in a similar fashion. So what is important with automation tools is scalability. What we did, we tested data on AES with different number of rounds. So we varied from one round up to 50 rounds. And we can see that in a case of 50 rounds we have over 10,000 nodes and over 16,000 edges. And yet the analysis time is still below 40 seconds. And the memory consumption is below half GB. And the analysis was done on a relatively older Core i7 processor with just 8 GB of RAM. So to conclude, we propose the methodology which is capable of finding vulnerable spots in software implementations of crypto algorithms. We created a tool which implements our methodology. It takes the assembly implementation and the user-specified output criteria as an input. And then it outputs a series of vulnerable nodes with subgraphs corresponding to each node and with equations corresponding to each subgraph. By this, we found a new attack on present AT which exploits weaknesses which are not actually visible from the cypher design level and can be only found when targeting the implementations. As I showed, the tool is scalable and it is capable of analyzing current algorithms efficiently. Thank you. Any questions? Thank you for the presentation. Would it be possible to use your tool to prove the security? To prove the security. I'm sorry, it's still... I think you were saying would it be possible to use this to prove the security of the implementation? Okay, so actually, we have a follow-up to this work which also automates the last portion of the analysis. So it uses a set solver to actually solve the equations. So for this, the formal proof is sound. So which means in case data finds some vulnerable spot and we do all the analysis, we do the subgraphs, the equations, then we solve them by set solver, it is a proof that this vulnerable spot is really vulnerable. So it can be really exploitative. However, so far it doesn't work from the other side. So it doesn't guarantee that it finds all the vulnerable spots. Maybe time for another quick question, if anyone. So sort of a link to that, would it be possible to use this to sort of test a countermeasure? Can you distinguish between faults that would be caught and faults that wouldn't be caught? Yes, so far, yeah, of course you can analyze the countermeasure. But you need to take into account that it does just single faults. So let's say if you have already done the single-measure, in order to break the countermeasure, you need to inject at least two same faults into each of the circuits. So yeah, you can test whether it is safe with respect to single-fault adversary. So it is also for a follow-up work to do multi-fault adversary to analyze more comprehensive countermeasures. Thanks. I thank the speaker again. Thank you. Thank you.