 on glitch resistant masking revisited or why proofs in the robust probing model are needed. So this is a joint work with Torben Moose, Amir Moradi, Tobias Schneider, and Francois Xavier Standard, and Tobias Schneider from NXP will give the talk. Yeah, thank you. So yeah, due to all of the talks, this might be actually a great short talk because Lauren already talked about a lot of the concept that I'm going to talk about in my presentation. So as I tell you to suggest, we are looking at glitch resistant masking, so basically hardware-oriented masking schemes and we analyze the security and what we can actually expect in practice. So I will first start with the introduction, talking about all the security notions that we used to help you maybe better understand what results we achieve later on. I'm not going to talk in much detail about physical text, just that our focus is on the masking counter measure to start such an attack. And the basics of masking is that you encode your sensitive variables into multiple shares and then you compute securely on these shares using a mask algorithm, like in this case F prime. Now if you have designed that correctly and also implemented it correctly, you would expect an exponential increase in your security of your protected circuit. Now the design of such protected algorithms actually not a trivial and there are numerous examples of early masking schemes which were later found to be flawed and to not provide to security which was expected of them. The effort current masking themes usually come with an extensive proof of security in the probing model which Lauren already talked about. And just to recall the basic idea, so we have our circuit and we can place pros inside the circuit and we need to show that any combination of these probes do not leak any sensitive information. And if we do that, we can actually then claim third order security or T order security for our circuit. Now this approach doesn't scale so well when you increase the size of your circuit or your algorithm and the number of your probes because then you get numerous combination that you need to be aware of. Therefore, usually rely on some form of composability where we for example do not consider the complete circuit at once, for example, mask IS. But instead we analyze the sub-modules first, for example like a multiplication gadget and we try to prove some security for these smaller modules, compose them securely with some specific rules and at the end we can derive the security of the composition of the whole circuit. Now as already talked, introduced by Lauren, a common tool to achieve this notion of composability is so-called non-interference or strong non-interference. Now if you do not have like these extensive proofs, that does not mean that your mask algorithm is actually insecure, so you could be actually lucky that in this case you actually already achieve security. However without any proofs, it could happen that you have flaws in your design. So you could either have like a local flaw where the module itself that you analyze actually does not provide the probing security that you expect. So if you have like a second order mask multiplication for example, that's in sec with just two probes. And on the other hand, there are these compositional flaws where each module for itself is locally secure so there's no tech with two probes. But if you put them two together in a circuit, it creates a flaw and a possible attack. Good, now besides these theoretical flaws there are also problems in practice because the probing model assumes like an ideal circuit it does not cover the glitches natively. Therefore in parallel to all the software oriented masking schemes there was a lot of research done on trying to tolerate religious and make masking schemes glitch resistant in hardware. And recently there has been a high number of masking schemes which actually basically do that and they try to achieve higher order security even in the presence of glitches in hardware. Now due to the lack of a formal model which actually combines both local and composability for these hardware circuits, most of these publication actually more focused on the local security. So they show glitch resistant and this is actually very good to them. They show local security and achieve security for the modules itself. But they usually do not make any extensive claims on how these modules can be composed later on in a secure fashion. And to solve this gap there as already introduced by learn the so-called robust probing model which basically formalized a lot of the notion that we know before to create like a unified model which can be used to show both local and composability for these hardware circuits. And a paper will later argue that this is actually very essential that not having it can make you vulnerable to a lot of these flaws that we've seen before. Go. So to give you an overview of what we did. So we basically took all of these hardware masking schemes and we looked at the security of them because none of them had like an extensive proof in the robust probing model. So we expected that at least some kind of words were found. And we were correct. So for each of them we found either a local or a composability flaw which further strengthened the case that you should use like a unified hardware security notion to actually prove the security of masking and masking schemes. We further also did some experiments to actually evaluate the practical impact of the flaws that we have found and if they actually reduce the security that you could expect in practice. And in the end it becomes a conclusion that you should always verify both the local and the composability security of your masking scheme in an adequate model. Either using a generic proof in the robust probing model or maybe the tool which was presented in the first talk. So before I come to the flaws I might want to give a disclaimer. So in all of these masking papers they first introduced some mass gadgets like multiplication and they used it later on to implement for example the AES at specific orders. And the specific instantiation are usually secure. So we did not find any flaws in them because they have been extensively analyzed by the authors. However if you want to use now these mass gadgets in your own design and you have like a different type of compositional maybe also at higher orders you will run into these flaws and it could result in an insecure design. Now let's first talk about the local flaws. So the first scheme that we actually analyzed was the consolidated masking scheme. First proposed as crypto 2015 and then later on in chess 2016 was used to implement AES with D plus one shares. And in the paper they gave concrete instantiation for first and second order which are actually all right. But if you read the paper it would seem that the construction is actually generic and can also be used at higher orders in two. In particular this ring refresh that you can see here if you read it like this it seems that it's also secure for order higher than two. So that's what we did. We took like the second order mass gadget which is a mass multiplication and we extended it from second order to third order using basically the same structure. So we have here the same cross product and the same refresh layer in between with like the same structure and the compression layer and everything. And since it's a third order masking scheme we would expect that we are actually secure against any text with three probes. However in our analysis we found that if you would probe like these specific spots I mean there more but just to give you an example if you would probe these three specific spots you would actually leak some sensitive information because most of the randomness in between here is actually canceled out in the compression layer. Now this floor is mostly due to how the refresh is done in the string structure and the authors already proposed a fix so that we should take care of this local floor. However, considering the composition security is still an open issue because you have to look at it again and maybe in this unified approach. So due to lack of time I'm not going to talk into detail about the other local floor that we found but it's regarding domain oriented masking where we found the D half plus one order floor using these extended probes that Lauren already was talking about but this is only in the e-print version of the paper where they proposed like an alternative multiplication scheme. So the normal DOM multiplication should not have any local flaws. Now coming to the compositional flaws. Now compositional flaws are a bit harder to combine because you have to because there are so many different combinations that you have to consider. However, when we looked at this generic low latency masking scheme for example, we also found that they used the CMS refresh like the string structures before they proposed to use it as a refresh in the scheme. So this would basically mean that the flaws that we have found before propagated from one paper to another. So we also expect this masking schemes using this refresh suffers from the same flaws. On the other hand, we also analyzed this unified masking approach and also found like a systematic composability flaw which mostly stems from the fact that they did not really limit how you can compose their mask multiplication. So what's actually important maybe to get us that this composability in hardware is actually quite complicated because you should not analyze these parts separately. So what we did is that we took one circuit which was glitch resistant. So it had like local security and just try to add an SNI refresh at the end. And what we found is this is actually not sufficient to achieve both local and composability security. Therefore, it's actually necessary to use a unified approach which covers both and also the hardware defects in one model. Now, coming to the practical session, now we try to actually run some practical experiments on a secure board and try to detect all flaws with a t-test. And what we found is that actually all of our flaws are practically detectable. However, they're not necessarily reduce the practical security. So what we mean with that is that in the case of CMS, we had like this third order mask gadget. So we would expect that no attack with three probes should be possible, but with four it should be truly possible. However, do our flaw, there is an attack with three probes and we actually could detect it here with this test. However, to detect the third order flaw, it actually took a lot more traces than just detecting like a fourth order unirate test. So in practice, actually an attacker would use a higher order check instead of like the third order flaw that we found. However, we should say that all of our flaws are multivariate, so actually finding the exact places which you should combine to get like the maximum ticketed actually not that trivial. So it might be the case that it is possible to actually have like a better maybe exploitation of this flaw that we found. Also it's important to note that we only looked at it at rather low order, so we would be able to detect it actually, and also only for very specific implementation. So just because for our case it was not, it does not necessarily reduce the practical security, there could be cases made for higher orders where it's actually very impactful in practice. So what we also found during our practical experiment that the placement of registers is actually very important. So this was already discussed for threshold limitations that use the registers to stop the propagation of glitches. However, in one of the initial e-prints of DOM, it was actually initially claimed that you can use a multiplication scheme without output registers. And this might work for the specific implementation, but it does not work with free composability. So we found a count example where you have two multiplication stages, and if you leave the output registers between these two stages, it is actually not secure, and you get actually a lot of glitches. Now to conclude, so what we found is that actually extensive security pools are not as established in hardware masking as it is for software masking. And this was mostly due to a lack of an appropriate model for most of the years. And our analysis has actually shown that due to lack of these proofs, there are actually flaws in all of them that we analyzed. And while the practical impact could be limited, it's still an undesirable source of risk that you do not want to have in your design. You would rather get rid of the flaws and then have a proper secure implementation. Now what we found during our writing that currently only the adapted DOM in-depth multiplication was actually robustly proven secure in this robust probing model. So it enables you to have robust local and compositional security. However, this doesn't mean that it's the only gadget which can be proven secure. So as part of future work, I guess it would be to fix the flaws, proof the existing schemes and then build on that to design new and improved schemes on it. That's it. Thank you for your attention. Are there any questions? Any questions? So we have ample time for questions. I have a question. So did you find a gap in the analysis of security proof and then found out the attack or you found out an attack and then you spotted the gap in the security proof if there was one? I mean, we found the gap in the security proof because there was not really any specified security proofs regarding the composability. So yeah, I mean, we had a look at it and then we also used some custom tools and maybe also some other stuff like Masquerif to maybe find these flaws. But yeah, thanks a bit. Any questions? So then let's thank the speaker and all the speakers of the session. It's time for a break and we'll be back by 10 past.