 So, this brings us to the last talk of this session, and just 2018. It's on CIFAR, which is Exploiting Ineffective Fault Inductions on Symmetric Cryptography. It's a joint work between TUGRAZ and Infineon, and the work will be presented by Robert Primas from TUGRAZ. Okay. Hello, everyone. Thanks for the introduction. As already mentioned, I'm going to talk about CIFAR, Exploiting Ineffective Fault Inductions on Symmetric Cryptography. And I would like to start this talk with a quick outlook. So what I'm going to present is some kind of new fault attack that are quite hard to prevent in a sense that they defy both detection and infective countermeasures. And as a matter of fact, they also can cope with mask implementations. However, this is actually covered in the follow-up work, which is why I'm not really going to cover it in this talk. There was a quite versatile in a sense that they allow an attacker to induce faults at many different locations during the computation of some kind of cryptographic function. And it even works with quite a lot of different types of faults. It's even applicable to quite a large variety of symmetric schemes. And as we will see, we've evaluated this kind of fault attack on quite a variety of different platforms to basically prove that they are actually a relevant in practice. So I would like to start with a quick introduction to fault attacks and essentially countermeasures against fault attacks. So what are you doing on fault attack? Well, basically you have some kind of cryptographic implementation that you want to attack. And usually what you want to do as a first step is you want to be able to get some kind of physical access such that you can set, for example, plaintext and observe ciphertexts. Then you want to induce some kind of fault into the computation such that you can observe a possibly partially or completely erroneous ciphertext. And then what you usually do is you collect or correct ciphertext corresponding to the same plaintext and determine parts of the key by doing a guess on a subkey and performing some kind of verification based on this pair of a 40 and the correct ciphertext. Now of course this goes under the name differential fault attack and is known quite well in the community. Now usually we don't only consider attacks but also countermeasures. So how do you prevent yourself against such attacks? Well the first and probably also quite effective countermeasure would be to use some kind of redundancy to ensure that faults do not really affect the computation. So what you could do for example is instead of computing your cryptographic implementation once, you could compute it twice and at the very end simply compare the two outputs such that you only release it if actually both computations match up. By doing so you can prevent yourself against the tackles that just induce a senior fault in the computation. Now of course a attacker could do something like this and basically inject the same fault in both computations such that the result matches up and the fault is ciphertext is released. And in order to cope with that you could do things like adding more redundancy or doing encryption, decryption, redundancy, using masking, etc. Now there are also different kinds of fault countermeasures other than detection based countermeasures. For example in an infection based countermeasure what you do usually you also use some kind of redundancy but also interleave computation and usually also dummy rounds. I'm not going into too much detail here but basically the idea is that once an attacker has injected some kind of fault into a computation this countermeasure makes sure that this fault is in some sense amplified such that the output, the fault the output is not related to the key anymore. Meaning that if an attacker would try to combine again correct and the fault is ciphertext does not really a meaningful way in how to do that. Now of course there are still attacks out there that could attack such a countermeasure but they are usually quite hard and require or have high assumptions on the attacker. Apart from differential fault attacks there is also quite a few other fault attacks in literature. So for example in 2007 Clavieret or proposed ineffective fault attacks and the nice thing about those is that they actually exploit only correct ciphertext and by that I mean of course you want to check a fault somewhere but every now and then a fault isn't actually causing a run-off computation so in some sense it's quite similar to a safe error attack. The problem with this attack is that it usually requires precise faults and the effect of a fault has to be known by the attacker which is not really always the case in a practical scenario. A quite different approach would be to use statistical fault analysis as proposed by Ford R in 2013. Here the nice thing about this attack is that it works with basically any type of fault even if the attacker doesn't even know how this fault attacks affects the computation. The problem here is however that this attack can be mitigated quite easily by using for example the detection or infection based countermeasure that I have presented just before. So our idea was can we somehow combine these two approaches such that we come up with a new kind of fault attack that has these both cool properties that we solely rely on the exploitation of correct ciphertext and still can work with quite a lot of different faults even if we don't even know what they are doing. So in order to explain how this statistical ineffective fault attack works I want to stick to an example on AES. So what we can see here on the white is just the last three rounds of AES and one of the observations that we want to make here is that the distribution of state bytes for example in route nine over the course of multiple encryptions is uniformly distributed. Now that's not really surprising since AES is in pure random permutation which means that this is basically how we expect such a function to operate. Now what you want to do is now we want to use a fault somewhere between mixed columns in round eight and nine. And the goal of this fault injection is to cause some kind of non-biased sorry non-uniform distribution in some parts of this AES state for example as illustrated here. And in order to do that you have actually quite a lot of choices you can work with stocked forts, random forts, instruction skips, bit flips and even when it comes to the granularity of the fort you can target a snippet, a whole byte or even a couple of bytes. So the effect could really be something like this or like that or like that so you do not really care as an attacker as long as there is some kind of non-uniform distribution. Now as I mentioned before we want to achieve a fault attack that actually works even in the presence of fort counter measures meaning that an attacker does not really get to see any faulty output. Now an interesting observation that you can make here is that forts can even achieve this property that we observe non-uniform distribution if we just restrict ourselves to ineffective forts. So the way to think about this is that if whenever we inject a fort we may or may not receive a cipher text depending on if the fort has affected the computation or not for example in a redundancy based counter measure. So in a sense you can think about this scenario or the fort as some kind of filter that gives an attacker access to just a subset of all the possible correct cipher texts as illustrated here for example. Now how likely is it actually that an ineffective fort can cause some kind of non-uniform distribution in a state byte? In order to convince that this is actually quite likely I have prepared a very simple example. So what we can see here is just a simple end gate and we see basically two input bits that are uniformly distributed and we want to explore how forts can affect the distributions of these inputs. So just for sake of simplicity let's just forget about the output for now. And as a first example let's consider bit flips. What would happen if you have an attacker actually injects or performs a bit flip on the first operant here? Now it's actually quite easy to see that if input of an end gate here for example is uniformly distributed and a bit flip isn't really going to change its distribution. However if we restrict an attacker to only observing these scenarios when bit flip is ineffective this basically means that the other operant has to be heavily biased to a zero because every time we perform a bit flip in the first operant here this basically means that we induce some kind of difference that has to be eliminated at some point and this is only possible in this scenario if the other input is a zero for example. Now what about random forts? It's quite simple to see again that the random fort doesn't really affect the first input because by definition if we randomize a bit its distribution is still random and uniformly distributed. Now again if we just have a look at the ineffective scenarios we again see that the second input is heavily biased towards a zero and the reason for that is simply that a random fort is nothing other than just a bit flip that occurs just in 50% of the cases meaning that in a couple of cases we need a zero to compensate this difference that we have introduced and in the other cases we do not. So let's assuming that we have some kind of set of correct ciphertext that resulted from faulted encryptions. How can we actually use them to recover a key? Well that's quite easy and actually equivalent to how you would do it in a statistically faulted tag. All you need to do is you want to guess 32 bits of the round key in round ten and then basically you want to reverse back to round nine where you originally injected the fort. And then you can measure the uniformity of the state bytes using an arbitrary matrix for example in our case we used the squared Euclidean imbalance and what we should expect is for a round key candidate we should expect that all the state bytes are distributed uniformly however for a correct key candidate we should expect that the distribution of the state bytes is not uniform but actually some kind of non-uniform distribution meaning that the key candidate that corresponds to the highest non-uniform distribution or the highest SAE in this example is most likely the correct one. So let's talk about a few of the practical results that we did. So for example at first we targeted a simple software implementation from the RVR crypto lab and of course we implemented some kind of detection based counter measure that ensures that no faulted ciphertexts are released. So we injected forts via clock glitches in round nine and basically we observed that after about 1,340 encryptions we received about five correct ciphertexts. Now how can we explain these numbers? Well in this case for example our clock glitches caused some kind of stuck it forward in one of the state bytes and if you do that then intuitively a fort is only going to be ineffective in about one out of 256 cases meaning that if you want to collect about five correct ciphertexts you need about 1,300 faulted encryptions and this was enough to recover key bits for this implementation. Now we also performed the same experiment on another device for example in 88 Smeagot 256 A3. This time we didn't really target a software IS implementation but a hardware IS code processor on this macro processor. Now as you can see the numbers are quite different. The number of faulted encryptions is similar however the number of correct ciphertexts is quite different. So why would that be? Well the problem here is we don't really know what our fault actually did to this implementation here for the hardware IS code processor so we cannot really tell but all that we actually care about is that the attack works. So you can see even on quite different platforms you can achieve similar results even if you do not really know what your fault is actually doing. Now I also talked about infection counter measures at the beginning so how about them? So in order to test our attacks against infection counter measures we had a look at an implementation from Hoops and Moudre at all and here it's basically we took a software IS and on top of that we implemented this infection counter measure. So in this case for example this would mean that our IS consists of 22 riddle rounds and 11 dummy rounds and then the attack is quite the same as before. We simply try to find round nine and inject some kind of fault in there and what we can see for example in this case is that about 6,500 faulted encryptions were necessary in order to gather about two 25 correct ciphertexts which was sufficient to perform key recovery. Now you can play around with the numbers here and increase the number of dummy rounds as you like. For example if we use 22 instead of 11 dummy rounds we can see that the number of 40 encryptions that are needed for the attack increases from roughly 6,000 to 9,000 and also for 66 dummy rounds we see for example roughly 46,000 for the encryptions that are needed in order to attack such an implementation. Now in summary cipher is a new kind of fault attack that actually defines popular fault counter measures like detection and infection. It does require quite a lot more faulted encryption than for example a differential fault attack but the nice thing here is that we only need one faulted encryption, one fault per encryption independent of how much redundancy is actually used in your implementation. We also do not really need precise fault locations. There are basically a lot of choices when it comes to where we want to check the fault here. And as already shown describe the type of attack works with many different kinds of faults even if the effect isn't really known to the attacker which also makes this probably a quite competitive choice for attacks against implementations where you do not even know the implementation. Now there already exists two fall-up works to this paper and one of those was presented at SAC about a month ago. So there we had a look at authenticated encryption schemes and even though we had a specific look at sponge-based schemes there really the takeaway message here is that this kind of fault attack works against pretty much all of the authenticated encryption schemes for example or the CISO finalists, sorry CISO finalists. There is another fall-up work that will be presented at Asia Crypt and here we basically explore how this attack performs against implementations that use masking on top of having already some kind of fault countermeasure. And here the takeaway message is that it basically performs equally well with no real overhead. Even if you just hit a single share of some kind of shared implementation. So essentially this attack is independent of the degree of masking and redundancy that you are using in your cryptographic implementation. Thank you very much for your attention. So for the sake of time we'll just take one question. Hello. OK. So would a reasonable countermeasure for this attack just be that the encryption module shuts down or refuses to use the key anymore once it detects one fault in the encryption? Yes, sure. So as you have seen we need quite a lot more faulted encryptions in order to get this working for example compared to a differential fault attack. So if you have some kind of mechanism that detects a certain number of faults and it is able to shut down the device or destroy it even, this could work. Yes. OK. Yes. So one more. The differential fault attack that you showed in the pop-up please slide number three. Does it work for non-deterministic encryption schemas? Sorry for what? Does it work for non-deterministic encryption schemes? I'm not sure actually. Like when you encrypt the cycle? Encryptions with randomization. Encryption with randomization like? Non-deterministic it means when you encrypt the same plain text like multiple times you get different ciphertexts each time. Like a CVC? Oh, you mean if differential fault attack works there or if CFA works there? It's the same plain text. If you encrypt it like twice, you get different ciphertexts. Yeah. So this attack also works in this case? Yeah, sure, sure. OK. For example, if you look at the results here against authentication encryption, of course some of them are non-spaced. And you basically have to have this property that plain text is never encrypted to the same ciphertext. Yeah, so sure. Thank you. This is a ciphertext-only attack, yeah. Let's thank the speaker for the sake of time. Thank you. Thank you.