 Hello everyone, I am Kirti and today I will be talking about FEDS framework, a Comprehensive Fault Attack Exploitability Detection for Software Implementation of Block Cipher. This is a joint work with Indrani Roy, Chastra Rabeiro, Aditya Hasra and Swaroop Bunya. Moving towards the details of the presentation, fault injection attack is one of the most powerful form of cryptanalytic attack on cipher. A single precisely injected fault during the execution of a cipher can help to retrieve the secret key in few milliseconds. Fault injection is easy with the help of some of the fault injection techniques like optical fault injection, voltage glitching, clock glitching, etc. Demonstrating a simple fault attack on a toy cipher that take 2x input P1 and P2 can have operations like key addition, sub byte, diffusion function which happens n times and the final round key addition. If we inject fault before the last round key addition, the output changes as follows that is key is visible at the output. How effective is fault attack depends on the location of fault injected and the type of fault injected. There has been a huge amount of work in the last 2 decades to find the exploitable locations in block ciphers. And from 2013 onwards, there come some of the automated tools that find the exploitable locations in ciphers. The first set of tools like XFCEXP fault and AFA which work at high level representation of the cipher and these tools find the exploitable locations along with the key bits and the attack complexity. One example of high level representation is the BCS representation which is a HTML like language. The alternate direction of research is the tools that work on software implementations like assembly, LLVM, IR, etc. and find the exploitable locations from them. Categorizing these tools into two set of classes, the first class which work at high level, we call it as HLE tools and that does sophisticated analysis and the second class call it as the implementation level tool and these tools which work at implementation and consider simple fault models. So moving towards the cipher implementation, a cipher can have multiple varieties of implementation for the same underlying operations. The implementation varies based on its applications like underlying hardware, embedded system, high speed servers, etc. For example, a toy cipher can have multiple implementations like implementation one where the order of operations is equal to that of algorithm and for implementation two where the order of functions are same but within a function the operations are interchange that is second byte key addition followed by the first byte key addition. For implementation three which is a t-table based implementation where the operations are merged like sub byte, diffusions, etc. For implementation four which is a bit sliced implementation, one byte operation in the algorithm is represented as bit operations in the implementations and the sweet spot are different for different implementations of the same cipher. Hence it becomes an onus for the user to bridge the gap between existing high level tools and the implementation level tools. As the high level tool, even though there does sophisticated analysis, they have de-mitted applications and restricted to algorithms. Implementation level tool even though they work on cipher implementations, they have considered only simple fault models and does not consider the cryptographic properties. Hence we introduce the FETS framework that work at source code level consider cryptographic properties of cipher and can handle multiple fault models. Here we have the FETS big idea that helps to find the exploitable locations in the implementations with the help of HLE tools and we would like to use the HLE tool that does sophisticated analysis and also varieties of HLE tools like XFCEXP fault are available. It's important to note that a cipher can have multiple varieties of implementations and we would like to perform a vulnerability analysis at the implementation level. Finding them is not that easy. Let's now see the complications in doing so. For this we have considered different levels of implementations of the same cipher. For example, BCS and software implementation. Each operation in BCS is called the sub-operations and each operation in the implementation is the program expression. The order of sub-operations and program expression is one to one for implementation one. For implementation two, even though they follow same one to one mapping, the order of operations are interchange compared to that of BCS. For implementation three, which is a t-table based implementation, thus operations are merged and hence it follows one to one and many to one mapping. For implementation four, which is a bit sliced implementation, the mapping can be one to many, many to many and so on. To summarize, exploitable locations in implementations are not that straightforward compared to that of output from the high-level tools. Hence we need some automated framework that can automatically find the mapping between high-level representation to that of implementation considering all these mapping cases. For this we introduce the FETS framework. To find the mapping from high-level to implementation and find the exploitable locations in the implementation, FETS consider three basic properties like completeness where any implementations of the block cipher must realize all the operations and operation within a round can be merged and the position of functions can be interchange. We have also used a model checking tool to find the equivalence between two levels of representation. Let's have a brief overview of how model checking works in FETS. We have two levels of representations like high-level representation and software implementation and we see in the size the high-level representation to some representation which is similar to that of software implementation as the first step and in the second step we add some required assertions to determine the output of P of 1 equal to state of 0. Step 3, we generate the constraints and properties and we won't be going in details of this step. Step 4, we use an underlying set solver that is to determine what is defined in the BCS is what is implemented. To demonstrate the working of FETS mapping phase, we have considered different types of software implementations of the same cipher that take care of all the properties of mapping. Let's just quickly go through the mapping phase. We have the BCS and implementation ready and it starts from the first sub-operation A1 and program expression E1 and it started tracing from this and here we use the model checking tool to determine the equivalence between A1 and E1. So, the model checker take these two expressions and determine that they are equivalent and if they are equivalent then it is added to a table called EMAP. Moving further, it goes to next sub-operations and program expression and with the help of model checker and determine that they are equivalent and this continues until all the sub-operations in BCS are mapped to that of program expression. But things are not always this straightforward. Moving towards implementation 2, where we have the changed operation, it starts from the first sub-operation in BCS and program expression and it won't be able to find the mapping with the help of model checker. Then it goes to next expression E2 and determine that A1 is equivalent to E2 with the help of model checker. Then it starts from the first unmapped node E1 and find the mapping between A2 and E1. So, this also continues until all the sub-operations are mapped to that of expressions. So, this is for the interchanged operation and for implementation 3, which is a merged implementation, the first key whitening follows a one-to-one mapping that is A1 maps to E1 and A2 maps to E2. So, moving towards other functions like sub-byte, diffusion and swab as they are merged along with diffusion function. So, model checker won't be able to find a mapping for A3. So, it traces till the end of the implementation and try to find the mapping. And once it goes further and once it reaches the diffusion function, it finds the mapping between A7 and A3 and it goes further and find the mapping between A8 and E4. So, what happens to the unmapped node? From A3 to A6. For this, we use the information flow graph that is generated from the BCS. So, starting from the mapped node A7 and trace back and determine all the unmapped nodes. So, all these colored nodes map to the expression E3. Similarly, for A8, it does the backward analysis and determine all the merged node for expression E4. So, this is how merged implementation is handled. For implementation 4, which is a bit sliced implementation, here we need to give some extra input to the user stating that how many bits are realized to a 1 byte operation. For example, here we have considered 4 different expressions are realized to 1 byte operation in the BCS. So, it starts from A1 and traces all the 4 expression that are equivalent with the help of model checker. So, similarly for A2, it finds the next 4 expressions. And for merged operation in this implementation, it also uses the information to flow graph to determine the merged nodes. So, this mapping does for all the nodes in the BCS. So, the final output of mapping phase is the mapping table that contain the sub operations and program expressions. And from the table, it's clear that the sub operations can have 1 to 1 mapping, many to 1 mapping, many to many mapping and so on. This result are for the toy cipher. So, what about the real implementations like AES? For evaluating AES, we have considered 7 different implementations of AES. And the 7th one is the bit sliced implementation. Let's see how this implementation differs. For implementation 1, where we have key whitening, sub byte, shift row, mixed column, add round key, which follows the same order of the algorithm. It has a 1 to 1 map. For implementation 2, where we have interchange of byte and shift row. For implementation 3 and 4, which is a T table based implementation, where we have merged operations from sub byte, shift row and mixed column. For implementation 6, which is specially crafted for testing the scalability of the tool. Here we have merged operations and swapped operation. And for swap, sub byte, generally we follow the order of operation from first byte to 16 byte. But here we have considered from the 16 byte to the first byte. Let's see the mapping results from this. We have the graph that shows that mapping from sub operations to program expressions. Let's go through the implementation it is. For implementation 1, it shows that a direct graph is a 1 to 1 map. For implementation 3 and 4, where we have the merged operations, the number of expressions is really less compared to that of other implementation. And for implementation 6, which is specially crafted, the second function, sub byte, which follows a reverse order. And it also has the merged operations between mixed column and add round key. For the next implementation, we have 8 different expressions in this map to that of one sub operation in BCS. After doing mapping, let's now stitch this big idea to a framework called FETS. The figure shows the high level overview of FETS. They make you solve the high level tool that does sophisticated analysis. Let's demonstrate it with some example. So here we have taken XFC tool, which gives us the exploitable locations for different ciphers along with the derived key bits. As we have the result from the high level tool, which is the exploitable nodes at the high level representation, let's map them to that of software implementation. Using the second sub module that make you solve the FETS big idea. Once the mapping is done, using the equivalence mapping module, the next sub module, find all the sweet spot for different implementations of the cipher with the help of HLE output from HLE tool. Let's be happy that we have successfully find all the sweet spot for different implementation. Is this the complete set of exploitable instructions? Well, no. There can be many instructions that can influence the result of given sweet spot. For this, we use the fault evaluation module in FETS. For example, there can be different possibilities by which fault can be induced to these expressions, like A8 maps to E9. So, fault induced in T can also have effect on the state 0. So, in order to find all this expression in the complex cipher implementation, we have used fault evaluation module that is implemented using LLVM compiler passes. The entire module is implemented with LLVM as follows. The software code along with the exploitable expression from the previous phase is converted to IR instructions and then converted to control flow graph. And each IR instruction is considered as a node and the edges are added based on the control flow. So, we have the control flow graph for with marked exploitable expressions. We have used exploitable node detection module to determine all the exploitable instructions that perform a backward data flow analysis on the control flow graph. And let's now see some simple examples. For this, let's see, assume that this node is exploitable and for finding the exploitable instruction, we have used three set called relevant set, define set and use set. For finding the exploitable instruction, we need to trace the relevant variables. Finding the nodes that can influence the result of the relevant set is marked as exploitable. And the nodes that does not have effect on the relevant set is marked as unexploitable. This is determined by backward analysis. So, from this graph, the last node defined as unexploitable and all other nodes follows can influence the result of the relevant set. So, all these instructions are exploitable. So, the final output of fault evaluation module is all the exploitable instructions that can influence the result of the given sweet spot. Finally, we have designed our FETS framework. Let's just evaluate it on different cipher implementation. For this, we have used two different high level tools like XFC and EXP fault that find the exploitable locations for different ciphers along with the key bits derived. And making use of this, we have done the mapping and found the exploitable instructions. For fault evaluation, we have considered two locations like A420 and A496 for different HLE tools and the graph shows that the exploitable instructions for these HLE tools. The brown color node shows that these nodes can influence the result of both A420 and A496. Quickly going through the evaluation results so we have evaluated seven different AES implementations and implementations like Lefia, Chamelea, etc. The table shows that the evaluation time for different modules of FETS. For example for implementation 3, the number of expressions is 196 and the size of emap is 84 and it took around 98 minutes to find the mapping. And for fault evaluation, the size of control flow graph is 4299 and the percentage of exploitable instructions is 3.71%. As we have developed the FETS framework that finds the exploitable instructions in real world implementation and that to integrated on LLVM compiler, there is an open question of fault attack aware compiler framework. This is an open problem and as a first term, we have used FETS to design a fault attack aware compiler framework by incorporating redundancy based countermeasure. And this gives us the executable with countermeasures automatically inserted. As mentioned this is the first term and for more research you can refer the paper. So the conclusion of the talk is we have developed the automated framework that determine the exploitable locations in software implementations of block cipher. And we have developed the first automated fault attack aware compiler framework that incorporate countermeasures and automatically incorporated. And the exploitable instructions varies and that too depends on the implementation and we have done evaluations on different AES implementations and other ciphers. And that's all for the talk. Thank you for your attention and please let us know if you have some queries.