 The title is M&M, Masked and Max Against Physical Attacks. The authors are Laurene Meijer, Victor Arribas, Svetla Nikova, Vensi Nikov, and Vincent Rijmen. And Laurene will be giving the top. Thank you. You can see the slides. So thank you for the introduction. I'm going to be talking about M&M, Masked and Max Against Physical Attacks. So in the field of embedded systems, I think if you go back to the 90s, there are two very important papers. So the first one being, of course, the first paper on differential power analysis. That was in 1999. And then three years before that, even there was a first paper on differential fault analysis. So in the next year, the community has been working hard to create countermeasures against these things. So against side channel attacks, two important countermeasures are hiding and masking. In this talk, I'm only going to talk about masking. And you already know by this time in the conference what that is. Then against fault attacks, you need some kind of redundancy. So repetition is quite common, but also error detecting codes, or in our case, tags. And then once you figure out how to implement your cryptographic calculation with redundancy, you also have to decide what to do with it. So you could decide to detect faults, or you could try to correct them, or you could go for infection, which means that you want to, as soon as something goes wrong, something is faulted in the computation, you want to make sure that the output is completely random so that an adversary cannot get any information from that. So suppose that we have an adversary that can do side channel analysis and fault attacks combined to make an even more devastating attack. So then we have to combine two of these countermeasures. So we're going to combine masking with some redundancy. So we have here, like, a mask's plain text, and the redundancy is also shared. And then we want to figure out how to implement, for example, AES in a way that we obtain a masked ciphertext and also the redundancy of the ciphertext in shared form. So if you look at the field of thresholds, cryptography, it's quite common to say that masking is like the embedded systems variant of multi-party computation because, you know, it's based on Shamir's secret sharing. And then in recent years, multi-party computation, that community has been looking at active adversaries. That means parties that don't only listen to protocols but also actively deviate from it and thus inject faults in the calculation. So we could see that as the MPC variant of what we were trying to do if you want to combine side channel and fault countermeasures. So I see two ways of getting where we want to get. So the first one is to take this one, to take an actively secure MPC protocol and translate it to two embedded systems. And this is what we did at crypto 2018 with a scheme called Kappa. So Kappa, because it's based on MPC, it comes with very strong security guarantees but it's also very expensive. So the alternative route is on this side. It's to take an existing masking scheme and extend it with a fault countermeasure. So in 2016 at crypto, there was party which is threshold implementations extended with error detecting codes. And last year at chess there was also a polynomial masking countermeasure extended with fault protection. And now this year I'm going to talk to you about M&M. So let's start with the essentials. What can our adversary do? So we have an adversary that can do side channel analysis and for this we're going to use the very popular deep probing model. And then the adversary can also inject faults. So in most cases we're going to assume that faults are random. They can reach any part of the chip. We're not going to limit them in the number of bits that are affected. But maybe the adversary can also has also like a very expensive precise laser that can exactly change some values. And then since those lasers are expensive, we're going to assume that this can only be done on some parts of the chip. So we're going to assume that it only happens in D shares of the D plus one that we're using. And then finally we also want to consider in some sense combined adversaries. But this is quite tricky. I should come back to that. So what's the redundancy in M&M? We're going to use information theoretic MAC tags. So not cryptographic MAC, but information theoretic MAC tags. And it's very simple. You just take for every data block X, you are going to accompany it with a tag. The tag is simply a Galois field multiplication of the data block X with some key alpha. This alpha has to be secret. And for every new encryption, you have to take a new one. So the assumption is that if the attacker wants to inject faults and not be detected, then he should also inject faults in the tags. And since alpha is secret, the probability that he succeeds in keeping them consistent is like 2 to the minus km. Which is based on the size of these tags. So what's our motivation behind these tags? So suppose that alpha would be fixed. Then you can see this as sort of a linear code, which is kind of like the party adversary model. But the party adversary model limits faults in Hemingway. And we didn't want to do that. So alpha can be anything. And then if we look at combined attacks, we have to assume that the adversary can inject faults using some information from side channels. And if he injects a fault on X, then he has to correct it with some fault on the tag. But if we make sure that alpha is secret, then even if he has this capability, then he has no way of finding out what the difference on the tag should be. So M&M starts from an existing masking scheme. So there are many masked multiplications to be found in literature, like really a lot. So this is just an example of a first order masked multiplier. And this is what we're going to start from. The question is how do we do nonlinear operations when we have data shares and tag shares? So how do we compute on this? So with the normal data shares, we can do the same as always. Just use your masked multiplier. But then for the tags, if we use the same masked multiplier, you end up with a shared representation of alpha squared times X times Y. And well, this is not a valid tag for X times Y. But we can correct this by doing another masked multiplier with a sharing of alpha inverse. And then you have your multiplication on data shares and tag shares. Now you can see that we have like a scaling factor of three compared to normal masked implementations because we need three of those red poles. With this linear operations, you can make any algorithm for M&M, but it's a little bit expensive, so let's see if we can do better. Suppose you want to implement a power map. And this is quite common because a lot of S-boxes are based on power maps. Suppose X to the power 3. You have a masked implementations of X to the power 3, and you apply it to your data shares and to your tag shares. So for the data, you're fine. And then for the tags, you end up with alpha to the power 3, X to the power 3, which you can convert into a valid tag for X to the power 3 by multiplying with alpha to the minus 2. And alpha to the minus 2 is very easily obtained from alpha inverse because squaring is a linear operation in masking. You can do it locally on each share separately. So this is quite nice because there are a lot of power maps in cryptography. For example, AES is a Galois field inversion, the S-box, which is the same as X to the power 254, which sadly is not an odd power. However, suppose you have a masked implementation of an inversion and you apply it to your data shares and your tag shares, then you end up with alpha inverse times X inverse, which is very easily converted to a tag for X inverse by multiplying with alpha squared. And again, alpha squared easily obtained from alpha. So you can see that our scaling factor went down a bit because inversions are a lot more expensive than multiplications, especially in the masked world. So our scaling factor has gone a lot closer to 2 instead of 3. So with these building blocks, you can make M&M implementations for any algorithm. And remember, there are a lot of masking papers out there, so you can find a lot of building blocks in there to plug in here. But now the question... So we have figured out how to compute with our redundancy, and then the question is now what? We have to actually use this redundancy to have protection against faults. So one thing we could do is maybe do an error check. But then you have to unmask the difference between what the tags are and what the tags should be, which is alpha times Z. So we don't want to do this because actually this is quite vulnerable to combine the tags. So we're not going to do that. Instead we want to use infective computation. So back in 2012, there was a paper on infective computation which used repetition as redundancy. So we end up with two ciphertexts, and then it would do an infection using the difference between the two ciphertexts. So the difference is used to kind of randomize the output so that if there is a difference... Oops. If there's a difference, you want to make sure that the output is random. If there is no difference, you output the ciphertext. But keep in mind also that if both ciphertexts have exactly the same faults, then you don't detect anything. But so this proposal was broken in 2013 because there was a bias on this random mask R. We wanted to do something similar minus the flaw. So we have our redundancy in the shape of tags. So we're also going to infect using the difference of what the tags are and what the tags should be. So this is this part. But we can do this share by share. And then if you look at the unshared output, you can see that if the tags are consistent, then this part here becomes zero and you're outputting just the ciphertext. If the tags are not consistent, then we randomize this and output something random. So of course we want to check that we are not introducing a bias here like they did before. So suppose that a faulty evaluation results in a faulty ciphertext with the fault being delta. We fill this in in our equation and we can cancel the actual valid part of the tags and we end up with this at the output. So to be safe, we want to make sure that this output mask is uniformly random and this is easily checked. So this is the case because we draw alpha uniformly from the field and r is also uniform but not equal to zero. So you can check this with a very simple Python script. And then so we applied this to AES, but remember again, sorry, I cannot say this enough, there are super many AES S-boxes out there in literature. There was even one presented this year at chess again. And so we used the S-box from the Knudda from chess 2016, but there's a lot more choices out there. So you might have different priorities based on area or latency. There are first order S-boxes that don't use any randomness or there are S-boxes that are tiny in area but have a lot of latency and there are S-boxes that have better latency. So the numbers that we have in our paper are not the only numbers you can achieve. And then secondly, it's quite difficult to compare our results to previous combined countermeasures because everyone considers a different adversary model. We've all implemented different ciphers and we've all used different libraries. But that's why we decided to only look at the overhead factor of the combined countermeasure over only a side channel countermeasure. So let's look at these results. So if we compare to Kappa, we know that Kappa has a very strong adversary model and comes with provable security and is very expensive and you can see that obviously we are cheaper than Kappa. And then when we compare to party, for first order, we see that the overhead factor is almost the same. But again, keep in mind, so for party, if the faults are limited in hamming weights, they actually detect it with 100% probability. And so for us, it's more like the adversary still has a success probability of 2 to the minus km. But then when faults have a larger hamming weight, then party does not detect them and for us, still the success probability of the adversary is 2 to the minus km. So different adversary models. And then we also did some evaluation of our implementation. So for side channels, the established method is to use TVLA. So this is for a second order secure implementation. So we did a bivariate t-test. On the bottom half here, you can see what happens if we turn the countermeasure off. So there's leakage in a lot of places. And this is a matrix because it combines time samples with each other. And then on the upper part, you can see what happens if you turn the countermeasure on. The leakage disappears everywhere. And this is with 50 million traces. And then we also wanted to do a little check for faults. But for faults, there is not this established verification method like you have with TVLA. So we kind of had to improvise. So what we did was we adapted our fairylock, our VHDL description. We added some extra extra gates. This created some extra inputs to the circuit with which we could determine to inject the fault. And so these inputs, we sent random inputs to that. And we did about 50,000 experiments. And of these experiments, there were only 189 where we got a faulty surface that the output that was not infected. This means that our experimental rate of detection is 99.6%, which nicely corresponds to the theoretical rate because we were using 8-bit tags. So that also gives 99.6%. So if you want to know more about this verification methodology, the poster session on Monday had my co-opter Victor presenting the tool Verfi, which is kind of like extending what we were doing here, but making it more automated and more comprehensive. So what do you want to remember? We have this new countermeasure, which is a lot cheaper than Kappa, but doesn't have the provable security against combined attacks that Kappa does. And then we don't limit our faults in hamming weights like they do in party. It's also very versatile. You can plug in any masked multiplication or any masked inversion that is in the literature, or that even still has to be published. In the paper, we also describe how you can combine the effective computation with detection, because you might have an application where you want to know if something went wrong. You want the flag to go up like, something went wrong. So we describe in the paper how you can actually combine this with the effective computation countermeasure that we used. And then finally, there's a lot to be done for future work because getting provable security against combined attacks seems to be quite difficult. We also don't have any verification tools for these combined attacks. How do you verify if the implementation is secure against combined attacks? And then you could do some optimizations with M&M where instead of always updating the attacks to correct to the Maki alpha, you could actually let the Maki alpha change between, for example, AAS. You would go from alpha to alpha inversion and alpha, et cetera. This is a possible optimization. So that was my talk. And if this gave you a craving for M&M's, and you still have your hotel room, then there are some very overpriced M&M's in your mini bar. So thank you. Time for questions. Yes? Just a very short question. About the party, what you have shown in slide number 24. Did you implement party by yourself? Because it's AES and party... Party was led, no? LED? LED, yeah. But then you compare here the LED with the AES? No, I got that number from your paper. But no AES, the party is implemented. I know. But maybe it was a bad implementation of LED. I mean you didn't implement party by yourself for AES? No, I just got these numbers from your paper. Okay. Because the code, the error detecting code, for the LED, the size of the code is 4 bits, right? Because everything is based on 4 bits and AES, you are in 8 bits. You have to use a different code. Yes. But we didn't... Like I said, there's different ciphers, and it's LED for party, and I just got these numbers from your paper. Okay, but then... Did I understand correctly that you are comparing the result of the AES with the LED? Or you have the M&M LED here? We have here... So our first order size was 19 kilo gates, and then the AES that we're based on first order protection is 7.6. But then this one comes from your paper, and also in your paper, you were mentioning that Seychelles only was this size. Yeah, but LED? No, LED for you, AES for me. Then I'm right that you are comparing the area size of LED with the area size of the AES. No. Okay, probably we have to take this offline. Maybe you have to take this offline. Are there any other questions? If not, let's thank Lauren again.