 Hello everyone, my name is David Kniche and in the next few minutes I will present our work with the title Silver, Statistical Independence and Leakage Verification. This is the result of a collaborative work with my colleagues Pascal Saastrich and Amir Muradi at the Wohl University Boho. Over the last two decades, a lot of progress was made in the area of masking. This resulted in various models and security notions being published. So the general idea is to build a software tool that can verify these security notions. There already exist verification tools like for example Math Verif. But Math Verif is language-based, which means it performs security checks based on a symbolic leakage and rules used for simplification of these leakage terms. As a result, these checks are over-conservative and are not in direct conformity with a security notion. So our goal was to build a complete and sound verification tool for Math's implementations. Complete here means that our tool supports all well-established security notions. And sound means that our checks are in direct conformity with the definition. Our verification tool utilizes so-called reduced-order binary decision diagrams or short ROBDDs. A BDD, so a binary decision diagram, is simply a representation of a Boolean function. An example can be seen on the right. Each node represents the binary variable. Accept the leaves. They represent the output value of the function. The outgoing edge of a variable node represents if the variable is fulfilled or not. So the structure can be recursively defined. Where every variable node can be seen as a root of a new function, while the leaves are simply the constant functions that take 0 or 1. In addition to basic BDDs, ROBDDs are ordered, which means for every path from root to leaf, every variable is transversed in the same order. And they are reduced, which means they are minimized in a way that there are no isomorphic sub-trees and no redundant nodes in the BDD. To sum up, ROBDDs are canonical representations of a Boolean function. Now let me give a quick overview of how we use the ROBDDs. On the right, you can see a very simply digital circuit realizing a Boolean function. Here, every wire can be seen as a binary random variable, which takes either 0 or 1, depending on the input to the circuit. So Q1, for example, is a function of X1 and X2, while Q2 is a function of X2 and X3. And the output depends on all three random variables. So as a consequence, each wire is a Boolean function, which can be represented efficiently as an ROBDD. Now let's get to how we perform our checks, meaning how we check the statistical distributions of the wire using the ROBDDs. For that, we will quickly recap the concept of statistical independence. Two events, A and B, are said to be statistical independent if the probability that A and B happen is equal to the product of the probability of A and the probability of B. This can then be extended to random variables. Two random variables are said to be independent if the probability that X takes a certain value and Y takes a certain value is again equal to the product of the respective probabilities. Now for every possible pair of values, the random variables can take. We can simplify the check if we just consider two binary random variables. For this case, we don't have to check every possible combination. But it is enough to show that the condition holds for a certain pair of values, X and Y. More specific, one can show that if X and Y are binary random variables, they are statistically independent if and only if the probability that X takes 1 and Y takes 1 are equal to the product of the probability that X takes 1 and the probability that Y takes 1. As a result, making this one check instead of all possible four combinations of X and Y is already enough to conclude statistical independence of two binary random variables. As the next step, we will extend this approach to check statistical independence of two joint distributions over binary random variables. For that purpose, that X and Y be sets of binary random variables. Now to show that these sets are statistical independent, we have to show for every subset X prime of X and every subset Y prime of Y that the event that all values in the X prime takes 1 and all values in Y prime takes 1 are statistical independent. We have to do this for every subset. An example where the sets consists of two random variables is given below. For checking independence, we have to check these four cases. Now, let's make the connections to the ROBDDs. We can make the following interesting observation. The probability that all binary random variables in a set are equal to 1 is equal to the probability that the logic conjunction of all these random variables is equal to 1. Now, the logic conjunction of binary random variables is again a simple binary random variable which we can present as an ROBDD. To sum up, we reduced the check of independence of joint distributions of random variables to the check of simple binary random variables which can be realized utilizing ROBDDs. So far, we showed how we perform statistical independence checks over the joint distribution of binary random variables. As the next step, we will present how we make use of this approach to verify the security of masked implementations. So, we need to redefine all the well-established security notions by means of statistical independence of joint distributions and then check the independence utilizing our ROBDDs. First, let's consider deproving security and describe it in terms of statistical independence. If we have a masked circuit realizing an unshared function with input x, y and z, the circuit is said to be deproving secure if the joint distribution over every set Q of probes on wires of the shared circuit is independent of the joint distributions over x, y and z, meaning the unshared input. For first-order security, that simply means that every wire is independent of the unshared input. As a result, we have to check statistical independence of joint distributions and we already showed how we do this. At the next step, let's describe denon interference in terms of statistical independence. This mainly is derived from the work consolidating security notions by the Maya ador. Now here, the definition follows a simulation-based approach where the simulator gets access of a restricted set S of input shares. More precisely, a masked circuit is said to fulfill the notion of the non-interference. If for each set of probes Q of maximum cardinality D, there exists a simulation set S of input shares restricted to a maximum of D shares per input such that Q is perfectly simulatable using S. This simulation argument can be translated into probability distribution. Namely, the distribution over Q, given only the simulation set, should be equal to the distribution over Q given all the shares. Now, if we assume that the input shares are identically and independently distributed, we can simplify this to the statistical independence of the distribution over Q combined with the simulation set and the shares which are not in the simulation set. Again, as a result, we have to check statistical independence of joint distributions here. Our tool also supports to check all security notions in the robust probing model in the presence of glitches, which is necessary to consider for checking hardware designs. This involves simply a pre-processing step of each probe before the independence check is performed. An example is given here. The probe Q3 realizes a function with inputs from the last synchronization point, which means the previous register stage. To derive the glitch-extended probe in the robust probing model, Q3 is simply substituted with a set of its input to the last register stage, meaning Q3 is substituted with Q1 and Q2 in this example. Then, the extended set is used as probes for the check. Again, now we can perform our check using the ROBDDs. We also derived a new methodology for checking the output uniformity for a masked implementation. We will explain it here for a single output function with three shares. We showed that instead of checking that the probability for all valid sharing given the unshared value is equal, we can also check if all sets that do contain all output variables except one are balanced. Hence, we have to check the balance of these three sets in our example. As a result, we reduced the uniformity check to verification of balance of joint output shares and generalized it even for multiple outputs. How do we perform the balance check using our ROBDDs? We use the fact that a vectorial boolean function is balanced if and only if each component function is balanced. Every component function simply means every possible linear combination of the coordinate functions. Here, all possible linear combinations of that one to ZELM. One linear combination is again simply a single random variable and we can also perform the balance check of a single random variable utilizing BDDs. On this slide, you can see an overview of our supported features. We support a check of all well-established security and composability notions. This ranges from deep probing security over deep non-interference, deep strong non-interference to deep probe-isolating non-interference. All these checks can be performed in the standard probing model which is mostly relevant for software and also the robust probing model and the presence of glitches which is relevant to check hardware implementations. Additionally, we support checking the output uniformity. Now, let us give you an overview of the verification flow for a hardware design using our tool. The engineer defines its design using VHDL or Verilog. Then, he produces the Verilog netlist synthesized for example by the Synopsys design compiler. The resulting Verilog netlist file will then be passed into a custom netlist file which is the input to our analyzer. This analyzer is performing the checks and outputs the result. The result contains for each supported security notion the security order D and the first failing probe for order D plus 1. In this table, you can see some results of our tool for several different gadgets. The green tick indicates why verification times are given in the brackets. We also verified several mask encryptions like present, skinny, prince or AS. The results can be seen here. Now, we want to stress one advantage of our tool, the soundness. Meaning, our checks are in direct conformity with the security notions and we will not have false negatives. Which means we will not declare the design unsecure with respect to a security notion although it is actually secure. The example here is a gadget realizing Q124 taken from consolidating masking schemes by Reparass et al. Overconservative tools like for example a masked verif will declare that this design is not deproving secure although it actually is. This is simply due to the simplification of leakage terms to gain speed. So what the designer now will do is add additional randomness. Now, masked verif will say it is secure but the additional randomness was not required in the first place because it was already secure with respect to deproving security. So the designer introduced unnecessary overhead to the design. For larger designs, this overhead in terms of randomness will become bigger and bigger. So we consider being in direct conformity with the security notion a big advantage of our approach. Now, we give a quick wrap up about the advantages and disadvantages of silver. Silver is complete, meaning it supports all well established security know and composability notions. Silver is sound, meaning it is in direct conformity with the definition of the security notions and avoids false negatives. Which leads to less overhead being introduced by the designer. It also gives useful results. It returns, for example, the first failing probe, knowing this will enable a much easier fix by the designer. At the disadvantage, we see that our tool is slower than language-based tool tools like masked verif. So let me give you a quick demo of the tool. Let's assume the designer already made his code, so in the hl or verilog and synthesized it using an example library. And then the result of the design is the verilog netlist. And for one small example, which is simply a two input and with two shares which should be at the end probe isolating probe isolating robust secure first order can be seen here. You can see the netlist here and for the inputs and output Silver needs some additional information which you can give as annotations in the brackets you can see here and basically you have to say what is the clock what is fresh randomness and what are the single shares and for probe isolating or interference the indexing is important because for the security notion you need to give a specific index. And yeah, so you define what are the shares what are the fresh randomness and what is the clock and afterwards you simply go in the config file of Silver, you can define how many cores you want to use and zero is simply auto-detect of the cores and then how many memory you want to use then here you give the path through your file your very long netlist file which in our case was derived using the standard set library N, A, N, G, 45 and then you can basically simply run Silver so let me do this it takes a few moments and then you can simply run the verification and it will give you the result so this design fulfills for the first order everything even in the robust model except SNI robust so this is the D smaller equal to 1 indicates that and the probe at the end is the first failing probe for the security order so SNI robust is even failing for the first order with that probe and I robust is fulfilling the first order but is failing for the second order with that probe so it gives you useful information with what probes the jack fails to conclude with Silver we developed an easy to use tool for sound and complete verification of the security and composability of masked implementation in both software and hardware there are some additional information about Silver so you can find the tool on github following this link please feel free to download it and try it out feedback is always welcome here you can also find the eprint link to the paper and our contacts so my email address the email address of Pascal and also the email address of army is listed here so yeah please feel free to contact us if you have any questions or problems when running Silver thank you very much for the attention and for watching this video