 So our next presentation is X-Fault and Automated Framework for Exploitable Fault Characterization in Block Ciphers by Sayan Deep Saha, Debti Mukhabadyeh and Palab Dasgupta, presented by Sayan Shah Saha. Maybe I'll ask some people to squeeze in their places here in front of their people standing in the back. So if the people standing in the back, there will be plenty of seats at the front here if you want to sit down. Hello. Thank you, Dr. Tanstel for your introduction. So I'm Sayan Deep Saha from IIT Kharagpur and today I'm going to present our work called X-Fault, which is an automated framework for exploitable fault characterization in block ciphers. By exploitable fault, I want to mean those faults which can be used by an attacker to launch a successful fault attack at the algorithmic level. So fault attacks are in reality and we have to prevent them. There exist several countermeasures, some of them are extremely resource hungry, some of them are not, but many a time they do not provide 100% fault coverage. Now in practice faults are extremely repeatable. So if you can figure out one fault which can bypass your countermeasure and it's exploitable, then your countermeasure is not of any use. Now while designing precise proper countermeasure, especially for resource constrained environment, we really need to know which faults we do need to really prevent against. But the problem is that who is going to tell you? You don't have an oracle, right? But this information is extremely useful because if you have the exploitable faults, you can design precise countermeasure, you can test those countermeasures properly, and also you can select better ciphers, you can design better ciphers with more robustness provided against fault attacks probably. But there are several challenges involved. First of all, not every possible fault is malicious or exploitable. The fault space of ciphers are huge, of prohibitive size most of the time, and analysis is quite complex. For example, it took kind of 8 years to figure out the optimal attack on AES due to Professor Dunstall only, and even after that people figured out like new attacks at seventh round and all, it's game never ends. Now we have too many ciphers, like hundreds of them probably, I don't know, and more are going to come within couple of years with this NIST call for lightweight cryptography. So the call of time is an automation, which we require. What are the properties should we expect? First of all, it should be generic to be scaled for all possible block ciphers we have in hand. It has to be fast enough, and it has to be scalable for large ciphers like AES. In this context, there are a couple of works working at algorithmic level, the most remarkable one is due to Zhang's algebraic fault attack. It provides a nice generic representation of ciphers using polynomials as well as the faults, and use the SAT solvers to solve them. The problem with this approach is that it's not so fast and it lacks interpretability. It will tell you whether it's a fault is exploitable or not, but it won't tell you why it is exploitable. So that information is required, right? Another nice work is due to Gilia's Barthe. It uses programs in this technique, but this is mostly applicable for public ciphers. So there are gaps. When we take a deep view inside DF Attacks, how they work, we found that the main idea is to basically introduce a fault to reduce the key search space to some extent where you can do an exhaustive search practically. So what he suggests here, let's not perform the exhaustive search. It will take too much time. Let's automatically compute the search complexity. That's sufficient to understand. Now, the challenge is how to do it in a generic manner for every algorithm. Fortunately, we came up with one approach which we call as X-Fault. So basically, X-Fault takes two kinds of input. One is an executable of the cipher, and one is an abstract description of the cipher. Here. It also takes a description of the fault. Now, when it has a fault, it simulates the fault over the executable provided and generates some fault simulation data. Over the fault simulation data, it basically minds the fault simulation data and tries to figure out certain properties which give you some hint whether the fault is exploitable or not. After that, it uses some grab-based abstraction of the cipher and tries to tell if the fault is really exploitable and also returns the attack complexity, the attack procedure, complete attack path, the required number of fault injections. So pretty much everything an attacker or an evaluator needs to know about a fault attack. Now, there are a couple of results here. Just honorable mentions I've kept. Like the first one is for eighth round attack on AES S-Box. So this attack is due to Professor Townstall. We reproduced the attack with our tools within minutes and it took remaining give complexities to part of eight and number of injection required is one. There is a seventh round impossible differential attack also found out by our tool and we figured out couple of attacks on present. The most remarkable one in this list is this gift attack. Gift has been proposed last year at chess and this year we found optimal attacks on gift using our tool within minutes. So let's see how we do it. So for that we have a formalization. First we formalize the cipher itself. So the idea is to formalize the execution of a cipher. So we consider here two execution. One is the correct execution, another one is the faulty execution and we represent this as a sequence of states. Now, when you take the differential, we symbolically represent each differential as state differential delta ij. We are going to analyze this differential itself. Let's take a look in the parameterized fault model that we are providing. This is the state where I am injecting the fault. This is the width of the state. This is a very important parameter which determines the fault model and this is the location of the fault in the state say which byte has got corrupted. That's it. Now let's get in the main concept of our tool which we call as distinguisher. So what is a distinguisher basically? It works like a filter which filters out most of the part of your key space and returns you a smaller key space over which you can do an exhaustive search and correct key is guaranteed to be there, present there. Now, the distinguisher is manifested in the form of constraints over the state differential. We consider state differential as random vectors here. Now, variables inside the state differential becomes constrained when it becomes a distinguisher. How it gets constrained will come later. Now that results in a non-uniform nature of state differential distribution and this non-uniform nature or the bias in the distribution actually gives you the key filter. Let's take an example. It's an 8th round attack on AES. We put a fault here. It propagates like this and at this level you see there are nice patterns. We can observe like this column is correlated, linearly correlated and that gives you this nice set of equations. So this is one of the distinguisher in our picture. Now let's formalize DFA. How we really formalize a DFA? Not only the distinguisher, there are a couple of other things as well. The first one is an algorithm to evaluate distinguisher over the key gases. Now, if you have a distinguisher, a filter, you have to test all possible keys over that filter, right? Now if you have a key space of 2 power of 128, it's quite not possible. So you have to figure out a nice and clever divide and conquer policy to do so. The second component is the remaining key space complexity, the filtering capability of the distinguisher. What is the size of the key space? You have to search exhaustively later. So in our tool, we just automate these three steps one by one. The first step is finding out distinguisher for fault simulation data, as I've mentioned already. We use a metric for that. The metric is well-known Shannon entropy. The criteria here is that if a state differential is a distinguisher, if and only if the entropy of it is lesser than its maximum possible entropy. That actually indicates the statistical bias. Now to identify the constraints on the distinguisher, there are two possible cases. First of all, the random vector we are considering, whether each variable in that is statistically independent or whether they are statistically dependent. If they are independent, we can easily mine them out from the fault simulation data. But if they are dependent, we have to apply some other technique. Here we apply classically well-known up-priority algorithm for that purpose with mined-out relationships among the variable, if you give some data to it. Now using these two steps, we can figure out the distinguisher, their quality as well as the constraints they actually impose on your space. Let's take an example. So this is an example of impossible differential distinguisher. You see the variables are quite independent here. But none of them can take the value 0. So basically the range, it should take value is stringed and that causes the entropy reduction here. It should be 128, but it becomes 127.90. That makes it a distinguisher. The next example, we have already talked on this. See these nice patterns. Here the variables are dependent among each other. There are dependencies. These columns are dependent. And then that makes this state as a distinguisher. And our tool can figure this out quantitatively. Now once you have the set of distinguishers, we have to figure out the divide and conquer strategy automatically. How can we do that? We use a cipher dependency graph. That's the graph-based abstraction of the cipher. This graph is specifically due to present. These dangling nodes here represent the key nodes. And these blocks, complete graphs represent the S-boxes. This is the palm layer. Now you see there are 32 key nodes in these two layers. But if you consider evaluating this node of the distinguisher by guessing keys, but you see here 16, here 4, these red key nodes you have to guess. The number of red key nodes are only 20. So effectively, instead of key guessing of 2 power of 32, you are guessing only 2 power of 20. That gives you a divide and conquer effectively. Now after a couple of more steps, you can identify individual independent computation chunks in your cipher, which if you do, I mean, parallely, you can reduce the complexity a lot. And that effectively gives you the divide and conquer. Now, once you have the divide and conquer policy, you can quite easily figure out what is the evaluation complexity of the distinguisher going through. Once you have the distinguisher and the independent pairs, you can individually figure out the remaining complexity for each individual pairs. And you can combine them, giving you the filtering capability of the whole distinguisher. And that kind of completes the X-fold. You can compute the attack complexity in the form of remaining key complexity and evaluation complexity. The attack procedure is given. The required number of fault injection can also be returned. And after all it takes, it says your fault is exploitable or not. Now, this is one of the inputs of our tool. How we input the CDG graph, how you construct it. So you can see this is one of the S-boxes. And this is represented like just node by node. So basically a textual representation of this graph is presented. And internally it converts it to a graph. This is one. Now let's see an output. So this is due, this example is due to the GIF block cipher. This is one of the distinguisher that we use for GIF. The associated key bits are 32 in number. Now, what we found, instead of a key search of 2 power of 32, here you require a key search of 2 power of 11.53. That's a reduction. And the evaluation complexity is 2 power of 8. That is, you have to search the key in 8-bit chunks. Here is another output. So I was mentioning about independent computation chunk. Here it is one independent computation chunk. You can see that if you guess two key bits at a time, then you can evaluate this distinguisher. So this is from another layer actually. And it says that if you just guess two key bits at a time, you can get the whole key of AES. I mean, I'm a gift. They are 32 key bits in this layer. Easy. Now to conclude, this is the first time we have provided a mean of doing DFA completely automatically and in a scalable manner. And additionally it provides the complete description of the attack. There are several augmentations possible over this, like further generalization for key schedule attacks, DFI attacks. Since it's the optimal countermeasures, countermeasure vulnerability analysis, et cetera, but this is the first step. Let's see a demo on XFALT. So I'm going to show the eighth round attack on AES. So there are two kinds of inputs. One is the fault simulation data, represented as ARFF files. So here we show one of them, pretty much random. This has been generated by adding the keys, adding the plain text, and fault values, of course. The second thing is the abstract description of the cipher. It's a dot cipher file. So here you see there are two blocks, like begin block, end block, construct. And within that I represent each function of AES in this graphical form. And then you can internally construct the CDG inside. That's that the tool. Now let's run the XFALT. So we are selecting AES, because we are targeting AES in this case. So the distinguisher identification step is running. We have 11 state differentials to analyze. Now it is finished, almost. Now we are calculating the grab base, using the grab base abstraction. And in this attack we found that two distinguisher are required to be used head on. Now attack is complete. Two distinguishers have been found. So it reports evaluation complexity to be 2 power of 32 and offline complexity. That is the remaining key space size is 2 power of 7.97. That's roughly 2 power of 8. That gives the optimal attack on AES. Now let's see the two distinguishers that we have used. If you have them, you can reproduce the attack on any implementation. So the first distinguisher, evaluation complexity is 2 power of 32. And it reduces the key space from 2 power of 128 to 2 power of 32, roughly 2 power of 32 actually. And here is the second distinguisher, which reduces the key space further to 2 power of 7.97. That's roughly 2 power of 8. Now let's see the example CDG graph. This is due to the first distinguisher that we have evaluated. You can clearly identify the independent computation chunks. If you just compute over these chunks in a divide and conquer manner, you can do the attack scalability. So that's all. This project is funded by Synopsys CAD Labs under this title. Thank you for listening. So do we have any questions? So is this available on somewhere like GitHub? Not yet, but we are planning to make it available as soon as possible. Anybody? Sorry. So speak here. So is this mining part, does it depend on which inputs you are or on which plaintext you are applying? No, but you have to just give sufficient simulation data. That's it. But we found that the amount of data, number of simulations you have to do to get the distinguisher is quite less. I mean, for AES, I use two keys and couple of 50 plaintexts probably and I get the answer. It takes, it does not take much time. But I mean, this assumes this bit flips, right? No, it's not bit flips. You can provide many kind of fault models. We have tested with multiple fault, byte fault, nibble fault, everything. But still, like on algorithm level, I mean, if you would have like physical fault, whatever glitch or something, you may have input dependency then. You can say that, but this is an analysis at algorithmic level. We are analyzing algorithms. We are not taking implementation in account for the time being. Later, we'll extend it on implementation then those things will also be included in the fault model. It depends how you design your fault model. I mean, the abstraction of the fault, that's it. Thanks. Well, let's thank the speaker again.