 Let's start with masking. So the first paper is titled formal verification of masked hardware implementations in the presence of glitches by Roderick Blum, Hannes Gross, Renat Isupov, Bettina Kuninghofer, Stefan Mangard and Johannes Winter, and Hannes would give a talk. Okay, thank you for the introduction. So before I'm going to start this talk with a brief summary about what we actually achieved in this work, I want to start with the vision that we had in mind when we started working towards this topic. So that idea really was to create a formal tool or a formal method that would take a masked circuit as an input and would then tell us whether it's securely masked or not. And if it's not securely masked, we want this formal tool to tell us where things went wrong and why this happened. So what have we achieved so far? With our formal verification approach, we can verify glitchy circuits and I just say glitchy because I'm really referring to hardware implementations and not just to a graphic way of expressing Boolean formulas. Our approach doesn't require any intermediate modeling steps, for example, to re-implement this in software but works directly on the net list and it can be applied at different design stages. So when you first start to implement your hardware designs, we can already put the first modules in our tool and then it will tell you whether it's securely masked or not. But it can also be applied later on if you move towards the end of the line in the digital design flow. So when you have the back in the data net list and so on. It also works for higher order and for multivariate analysis. It is not tailored to a specific masking scheme so it works with every Boolean masking scheme. And it allows you, and this is really helpful to localize where your flaw is. And first, and most importantly, it gives a conclusive security state. And so the contents of the paper are the formal groundwork, but we also give a concrete SMD-based instantiation of our formal approach and test it against some real practical examples. These examples include, for example, the DOM multipliers, the domainoid masking multipliers, up to order 4, but also bigger circuits like the catcher S-Box up to order 3. And this is the biggest example we have of first order protected AES S-Box that we test against. So let's start at the beginning. Why do we actually need formal verification or verification of masked hardware implementations? Aren't there supposed to be any secure masking schemes? So first of all, we need to talk about what is the secure masking scheme. And we have a very nice way to express side channel resistance, which is covered by this probing model which goes back to the private circuit's paper of Isha et al. And this basically tells you that your mask implementation is side channel resistant. If it is secure against the probing test, it has the ability to place up to deep probing needles on your circuit. And if the attacker cannot extract any secrets, then it's secure in this probing model. And so what is a masking scheme? A masking scheme is in some way a projection of these rules set by these probing models on the canvas of a masked implementation. So it gives you the rules, but the masking scheme itself is implemented by designers of hardware, so there can be mistakes in the implementation of these schemes and also the digital design flow that takes this circuit as an input and processes it further and then it can be produced in both many tasks that change your netlist and also things can go wrong there. So we have, for example, masking schemes that look at this from a classical masking perspective or a more modern way is from the sharing perspective, but in the end this is always a managed process to mapping these schemes to the implementations. So implementation requires verification. And at least in theory there are two approaches one can think of. The first approach to verify this mask circuit is to either use empirical verification which is the predominant form in this widely used practice, but there's also a formal way of proving this. And so the empirical verification works as follows. So you take, for example, your supposedly secure AES core, you plug in the oscilloscope data into the power line and extract sidereal information and then you run some statistical analysis on the power traces that will tell you whether it passes the test or fails. The problem with this approach is that it's not conclusive. So if you don't find a flaw, you just don't know, maybe you haven't used enough traces to test your implementation. And if a flaw is detected, you don't know if it's a real flaw and where it actually originates from. So it could be everywhere from the circuit. It's also device-specific and it can hardly be used during the design phase of your circuit. So how about formal verification? Well, I thought the picture would say more than a thousand words. So in terms of formal verification, in terms of practice of formal verification and masked hardware implementations, there's really not much there. So if you would look at the software side, this would look a bit differently. But yeah, so in the hardware side, at least when you started, there was really not much there. So and with this set, I should also talk a bit about what we don't do or what we try to avoid in this, in our formal approach. So what we didn't want to do is a heuristical approach. So testing, for example, specific properties for a certain masking scheme. This would be, again, not conclusive, of course, informally. What has become very much popular, especially in the software world, is this notion of composability, which allows you to verify smaller parts of the circuit inside this composability notion. And this will then tell you if all of the parts are secure and to plug them together, then in the entire whole circuit will be secure. So we didn't do this because not all circuits or almost implementations fulfill this composability notion in a straightforward way. But this would be one meaningful extension to our approach. And as a matter of fact, so we're living in a really fast-moving world. So there's already a paper on this. So there's this paper on composable masking schemes in the presence of physical defaults by Faust et al. that does something very similar to our approach for this composability notion. So in our set about what we don't do, what is it that we actually do? So we started with this project about two years ago and for a long time we were really struggling to find something that really works. So we found some approaches that looked very promising for first order and didn't vary at the tax, but everything fails for higher order. So at some point we became really desperate until we remembered the roots of our information in computers engineering education. And so I think every student that studies something like this has heard something like, if you're really desperate if nothing works then just go for Fourier analysis. And so this is what we tried. So the interesting question is now, what is the Fourier analysis of the circuit? And so when we neglect time and look at the circuit and I also want to use the slide to introduce the notation I'm going to use in the rest of this presentation. So I always assume that we have a secret that is masked inside this variable SM that is masked by the mask MS. Then we have some other masks that are denoted with M variables and then we have some variables that are interesting or publicly known or something else, something that is not security relevant but also cannot provide security like a mask could do. And these are these public variables or B variables here. So when we look at this circuit and when we are neglecting time then we can just write this as a bolding equation. So this says nothing about time and behavior but just for the moment. So the next thing I'm going to talk about is this Fourier expansion and for those of you who were to talk about on-control yesterday already heard about this, this is also called the Worsh Transform. And the way this works is basically we take this bolding equation and wrap true to minus 1, false to 1 and then we can write each equation in a very elegant form so we can write a function over the input variables X as the sum of the Fourier coefficients times the Fourier characters and this Fourier characters are nothing else than all combinations or possible ordered combinations of variables that we have. So how would this look like? So we would end up with an equation that looks something like this. So this alpha here are my coefficients and then I add them up together times all combinations of my input variables X here. So how does this help? Well, there is this lemma of giant message that basically tells us a bolding function is statistically independent. For all variables it holds that the subset of this set of variables despite the empty set, although the Fourier coefficients should be zero. So what does this mean for our circuit? So if we set SM here, the equation S times MS. So S is our secret that we want to protect. So when we look at the Fourier transformation of this circuit then we see that we only have non-zero coefficients for terms where we have S joined with a mask together. So this would be insecure if we would have an S alone here or an S with a politically known variable but so far the circuit looks secure from our perspective. What's the problem with this? So if you go to bigger circuits and later on we're going to expand this to all possible signal timings then this really becomes quite inefficient and if it becomes big enough then it gets impossible to do this. So instead of calculating the exact Fourier spectrum our idea was to just do an approximation of this spectrum because we just want to know whether a certain value is a zero or not. So with our approach we're doing an approximation and this can also come up with some low spikes here which only can decrease our security so we can come up with false alarms but if a circuit is securely masked and we do this approach then I should always say it's secure, this is what we prove. And so the verification then works in three steps. The first step is that we label our inputs according to our Fourier analysis so this basically means that we just set the input labels here according to our variables except for the SM here which is S joined with MS then we propagate these labels according to some rules which depend on the Fourier spectrum of the functions that we're calculating and then we check for some secrets without any masks in this case it would be a secure circuit. So this propagation rules that we have are quite simple for a stable signal so when we don't talk about timing so we just label the inputs for example for this AND gate here according to the variables we have in there for non-linear gates like the AND gates we're doing the following rule so we're creating this labeling here where we join the empty set with the first input set with the stable set of the first input and the stable set of the second input and then we're doing also this point-wise set difference of both labels here for linear gates like an x-word this looks a bit differently so for this we only do the last part here where we do this point-wise set difference and for registers and all of just one input gates we just propagate the stable set so up to now we don't neglect the timing so I'm going to change this now so let's talk about glitches so this is really something hardware-specific and I want to discuss this on a much simpler or in a simpler circuit as we had before this is really just two XORs, a masked secret and some masks and so when we look at the output of the first XOR we would get S, XOR, MS because this is what SM is XOR, M1 and when we look at the output we basically get S, XOR, M1 because we cancel out MS so this looks secure up to now however if we assume that in the next cycle we would process a different secret so we also have different input signals but we assume that this masked M1 here arrives a bit later than all the other signals here what we get at the output is S had XOR, M1 which doesn't look bad, right? but the problem is so in the probing model it is assumed that an attacker places a probing needle on your circuit can continuously model what the circuit is doing at this point so you would not only get this equation here but it will also record the equation from the cycle before and when you combine this you can learn something about the difference of the secrets that you had before so this is then not secure this is not what we want to have and if the signals then settle again this flaw vanishes and this is basically what we call a glitch so a temporary violation of this probing assumption so in order to also cover this we need to extend our rules and we also added a second set here which we call the transient set which is here denoted in red and for inputs of the circuit we just do the same thing as for the stable set for non-linear gates we already have a rule that really covers the worst case so we haven't modified that but for linear gates where also glitches can happen as you have seen on the slide before we're basically going to use the same non-linear gate rule as before that covers the worst case scenario and then for registers we say the transient set totally disappears because registers are blocking one cycle from the other and so we then just propagate the stable set here again so let's have a look at this on a bigger example on the circuit we had before at the beginning and we just look at the transient set because this is a purely combinatorial circuit so again we are leaving the input as before and then we apply our non-linear propagation rules also for the XOR gates so we get this empty set the copy of the first input copy of the second input and then we also get the point-wise set difference so if we are doing this for all gates here what we then see is that this circuit is indeed not secure for transient signals and privileges because we see that we end up with signal combinations that contain the signal or the secret without any masks in them and this indicates a flawed circuit so enough of the theory we also took this approach and put it into a tool and our tool chain works as follows so we take a circuit description for example based on Beryloc or VHDL passes with an open synthesis tool which is called YOSIS and what you get from that is a circuit tree in JSON format that we are going to process further so this contains the gates and the wires so the connections of the circuit and then we need a bit of user interaction here because the user needs to tell us at the input of the circuit which signals are critical, which are secrets which are masks, which are public signals and what is the maximum protection order to them I want the circuit to be tested against so we take this information to a Python script that creates all the propagation rules that are talked before for the concrete circuit we are going to verify and with this and the constraints we are going to call a C3 set solver and this is then going to tell us whether the circuit is secure or not and if it's not secure we can ask for where is the flaw located and what are the signals that produce the flaw so with this implementation we so for this instance of our verification approach we tried a few exemplary circuits that are out there so we started off with verifying some basic building blocks of masked circuits like the ISW and the Trichina end gates which are known to be flawed and also our tool of course indicates this and we also tried some other building blocks like threshold implementations end gate and the main order masking end gate and for this we did the verification up to order 5 for different orders of the multiplier and so in this diagram you can observe the time and the verification order for different orders of the end gate and as you see the verification effort grows exponentially but what's also interesting to see is so finding a flaw is much easier so this is also what we observed in bigger circuits when we actually found a flaw then we would have found this much faster than if we solved this flaw then and run the verification on this but of course we also tried this against bigger circuits so we tried this for example for down catcher S-box so our first order verification took about 20 seconds third order verification about 25 minutes we also tested the file S-box file APN and the biggest circuit was the domain oriented masking protected AES S-box for first order which took between 5 and 10 hours of parallel checking in order to verify this to be a secure circuit so this brings me to the conclusion of the talk and I want to end with a positive note on the verification of masking or in the formal verification of masking so we really think that there is hope for practical formal verification of masked circuits and that this really can become not only an alternative but a replacement for empirical and horisical methods that are now the predominant form of verifying these masked circuits we feel that there's still a long way to go to cover everything and to make this so efficient that we can improve complete circuits and for higher protection orders but there's also lots of room for improvement and one way to go for example is this composability and the combined form of this composability in ocean and so on so there are really some ideas out there how we can improve our approach and this is just the first step so thank you so we have time for some questions you have a circuit which is secure without glitches and then with glitches it's insecure and the circuit is very big then the problem is that you have to decide is it really insecure or not because in practice I don't know if you want to make it secure against glitches it will be much bigger you probably need to add some registers but the thing is so we have the stable set rules and so the first thing that we do when we practically verify because this is really a tool that we use when we are going to implement new stuff so this is really a practical tool that is already in use the first thing we do is we just test for the stable set rules this doesn't have this huge exponential blow up so this works really much much faster than also applying these transient set rules so this is the first thing we do before we go to the transient set is there scope to add some probabilities in this setting like to say what's the probability of actually having a glitch because I don't know in design so we don't take concrete signal timings into account because this can also completely vary so if you are going to produce an ACG for example and you take two different devices then this can also have completely different signal timings or this could vary when you have different environmental conditions you could but I don't think this would make things easier actually so right now I think it's better to just verify against the worst case than taking concrete signal timings into account because also this assumption that you would have the signal timings is not quite realistic in India okay thank you for the very nice talk I have a question for like at the end of your talk you said that you could do parallel checking for the verification of masking limitations so I guess when you do parallel checking is for checking each secret like each bit of the secret separately yes okay so can you explain in a few words how you can do that because you put flavors on the nodes so you need flavors for each secret so how can it be faster with yeah basically what we are doing we just modifying the labels at the input by just removing the other secrets so for example if you take an AESS box you have eight secrets in there right and verifying against all of the secrets is quite time consuming so you want to do this in parallel and so what we are doing is we are taking all the labelings that we would have but just removing the seven other secrets like if it was public variables like if it was public variables for instance or you just remove the nodes we keep the masks this is what we keep because this is what we need because it can also become insecure because of this mask in some way but we remove the secrets okay thank you okay let's thank the speaker again