 This paper is about template attacks against the desk key schedule in actual implementations. My name is Johan Heisel and this is a collaboration with multiple co-authors from three different institutions. Two of them are Fraunhofer institutes. One of them is the German Federal Office for Information Security, the BSI. The motivation for this work were several e-print publications from several years where there was described an attack against a commercial security controller where single trace attacks led to significantly weak keys and also to remaining rest entropies of keys which were very low. So this was surprising and interesting and after reading those publications there were several questions which in our opinion were left unopened or unanswered. Namely are there really such wide distributions and are there really side channel weak keys and is this reproducible using state of the art tooling? Is this device specific to one specific commercial security controller or is it more general and does it even apply to other devices? What is the impact on what is the actual impact on three key triple desk which is the only real application of this nowadays and is it predictable these are those weak keys predictable through simulation? This was the start of our work and we started with an empirically study using a similar commercial security controller which was programmable for this investigation and we target the desk key schedule. We use a high precision EM setup, we de-cap the security controller, we perform measurements from the backside, we spent a lot of effort for alignment and then we did a t-test using a preliminary leakage assumption to detect measurement positions and used a correlation-based leakage test to select points of interest. To the desk key schedule, the desk key schedule is remarkable because it's very simple unlike the AES key schedule which for instance includes an S-box transformation the desk key schedule is much simpler it simply shifts and permutes key bits so the round keys and there are 16 round keys are simply created by shifting and permuting bits from the original key. This means that bits reappear in all the round keys and remarkably this also means that transitions between key bits on certain bit positions also reoccur. So this is depicted in this table here we see half of the desk key schedule we see the so-called register C so we see half of the 56 initial key bits and we see the 16 round keys in as one round key in a row and then what is highlighted here is that for two examples that specific key bits from the original key subsequently follow each other on the same position so for instance on a lot of occasions the bit zero follows after the bit seven and here in red depicted the bit zero follows on the bit 14 so if we look into the other bits this is similar so this is a different representation of the same key bits and the figure here shows all the transitions between key bits which occur in a desk key schedule. So the dashes are again the transition between those key bits and the two colors they indicate whether those transitions occur more frequently or less frequently. The red ones occur only three times and the blue ones occur 10 times. Now this is interesting because these those bit transitions those the number of those bit transitions is much smaller than if those bits would randomly be distributed across the round keys. In order to understand how the template attack should work in the best way we needed to understand the leakage model of the device in more detail and we approached this by precisely analyzing the leakage model through calculating SNS for value leakage so for the leakage that the bits have directly and for the leakage that occurs through the sequence of two bits. And we found that this device exhibits exclusively XOR leakage so that this device this specific security controller only leaks the XOR difference between subsequent bits. This means that we can group those XOR transitions into templates and we did this and created 7-bit templates and this also meant that we could use state-of-the-art key rank estimation for those independent template results and derive security levels from those template attacks. The dash boxes here represent how we selected the XOR transitions for the for the templates and and proceeded with the template attack. Now the results this is the first result of the analysis and this on this figure we see the security the resulting security level for 1000 attacks and we see a histogram of results on the on the Y axis and what is remarkable here and what is similar to the findings of those previous publications is that the results are widely distributed so unlike usually when for instance performing DPA where we would expect a certain narrow span of results we see that there is security levels resulting security levels from this template attack against the the key schedule which span from very low numbers to higher numbers. So the orange line here depicts the medium the average result which is still a quite high number given single days an attack single days but we also see that there is significantly lower security levels and we tested also specific or very special keys and we found that for two very specific keys namely a key with all zeros and the key with all ones the the resulting security level is as low as two bit even. And since this is a distribution it follows that the more keys we test the more we find which have exceptionally low security levels. Now if an attacker uses more traces than a single trace this improves the situation for the attacker and what we see here in those figures is the first figure is the same as before this is the case for a single trace for the attacker and then we have the case for three traces for an attacker and then the case for 900 traces for the attacker and we see that the distribution moves to the left meaning that the results for the attacker get better the security levels get lower and also the the mean security levels get lower. But this also means that this white distribution is not due to noise factors or that that can be averaged out. So if we use like 900 traces for an attack then there are several noise factors which we already averaged out. So this means that those noise factors are not the reason for this white distribution. This is a different figure and this shows the evolution of security levels over the number of traces. So here on the x-axis we have 900 traces and on the y-axis we have the result of an attack after this number of traces and what we see here is that the attack result asymptotically converges to a certain level. So we see that after a certain number of traces the result stabilizes and there is no further gain for the attacker meaning that the fact the noise factors that can be averaged out are averaged out then and the remaining the resulting security level stabilizes. In this in the left side we selected 10 random keys for this figure and on the right side we used we selected 10 keys which showed lower security levels and what we see in this from the comparison from the two figures is that there is an inherent security levels that the keys converge to and even if the number of traces is increased the security level stabilizes at a certain value. So from this and several other findings we conclude that it is the leakage model and also the switching noise from the key bits which determines the key weakness which is an interesting finding. Now as an overview and comparison from this work to the previous works as a summary we see that the results are similar. So the specifics a little bit different but for instance in this single trace attack from this related work there were actually four death executions per trace and so this is comparable to the case from this work when we use three traces and in every one of those three traces there is due to account the measure as it seems there's about one and a half death executions per trace the security mean security level in those two comparable cases is quite similar. So what we learn from this is that using a state-of-the-art and solid approach as described here and with described in more detail in the paper we it leads to similar results hence they are reproducible hence they are really weak keys and also the security level of keys is widely distributed but what does it mean for an actual application of death so we know that death is outdated in general but if death is used then at least it should be used in triple death mode with three keys and to to understand what this means for this kind of use of the death we we came up with a method to to estimate this security of a three triple death implementation based on the analysis or investigation of a single death attack and we we estimate this result for three key triple death by even allowing the attacker a mid in the middle advantage while using such a result and the figure here shows an empirical density of security levels so on the x axis we have again security levels and on the y axis shown here we have an empirical density and then we see four different graphs and the blue graph is the one that that is derived from the single trace results and as expected it shows the highest results so the highest security levels and then the attacker gains something when he increases the number of attack traces when he uses three traces it's the orange density and if he uses 900 traces it's the green density and we see that increasing the number of traces the distributions move to the left meaning that there is more keys with lower security levels so in as a result we see that a lot of the the security levels will remain in a quite high range but we also see that those distributions have long tails to the left and there is a certain percentage of of low security level keys in the table and with concrete numbers this means that on average in this row here on average the security level is still very high so it's still in the range of 80 to 90 bits but this also means or the results also show that there is a fraction of cases where the security level is lower than 80 bits for instance and the fraction of cases where this is happening depends on the number of traces used and for instance if a single trace attack is performed then we see that this estimation leads to an estimated dot 24 percent of cases which show a security level below 80 bits for three key triple days so this is not zero but it's still a very low number meaning that roughly for instance this is it can be thought of like every an attack on every 400 device shows a security level below 80 bits so what we asked ourselves is if this can be generalized through a simulation so and for this purpose we created a simulation where we simulated XOR leakage without any noise factors and performed the same attack and the results show that even in this simplified simulation we get a very wide distribution of security levels and even in this simulation we already see that there are weak keys to be expected with exceptionally low security leverage hence we find that the issue must be more general than applying to this one specific security controller and then we wanted to understand whether this simulation can help to predict reality so whether this simulation can be used to predict the resulting outcome of an actual measurement and for this purpose the figure shows the security level and we attacked a lot of different keys and we attacked them once in a simulated scenario and this is the the X axis and then it shows the results of an actual attack of the same key on the device and on the Y axis and if the simulation and the actual device would be perfectly equal then we would expect a perfect diagonal in this in these results but what we see is that this is not the case specifically the the blue group of of keys here shows only a relation between simulation and reality to a certain extent and this blue group of of keys is is a group of randomly selected keys so for randomly selected keys which are more representative of a real-world kind of scenario we show that the simulation and the reality have a certain relation or there is a certain predictability but this is not very good but then we we also tested this for for special keys for keys where about 90% of the key bits are either all zeros or either all ones so those are keys which are skewed so the the distribution of the keys is not uniform but is either very a high number of zeros or a high number of of of ones and for those kind of special keys the the red dots in this figure we see that the relation between simulation and reality is is is much more precise so there is a much more direct relation between the two and then from this we also learn hence that this this key weakness and and and this this this concept of of side channel weak keys for the desk key schedule is is a partly device agnostic so partly non-specific to a to a specific device and to to proceed further into understanding this we also tested the second security controller of the same manufacturer manufacturer and this led to very similar results the results were about three bits better in terms of the the security levels were higher but nonetheless it's still a case of a wide distribution and and we is still to be expected that there are weak keys then we used a totally different device we used an off-the-shelf regular general purpose microcontroller and stm32 we used the hardware desk engine of this microcontroller and performed a similar attack in this case we also again we tested for the leakage model and we found that the leakage model was completely different so this device leaks the values of bits not their transition not the x or between values and still an attack against this device is still leading to similar results in terms of there is a wide distribution of results and there is obviously weak keys to be expected so what do we conclude from this investigation we set out to to to answer questions that we found were left open through the series of publications that we referenced and we found through our investigations we found that this wide distribution of security levels and weak keys in fact does exist for a similar security controller and also exists for for different implementations and even for different leakage models so at least for leakage models such as an x or leakage model or value-based leakage model the desk key schedule if it leaks will lead to the to the case of wide distributions of security levels and weak keys why is this the case the desk key schedule seems very prone to this because this non-linearity in the the key schedule leads to the fact that bits and their transitions reoccur frequently this increases the amount of leakage that can be exploited by an attacker generally nonetheless given our findings we can say that the impact on the specific commercial security controller seems less dramatic than the original publications alleged with only a very small percentage of cases with a security level of below 80 bits after an extensive side channel attack what we find is left open through these results is that if in a similar scenario or in this scenario a side channel attack leads to results which are distributed and where the distribution is wide and maybe there is even outliers or few cases with with very low security levels then it's interesting to to to assess the security of such a device in in such cases it seems on the one hand it seems unfair to assess the security based on the average security level on the other hand it's difficult to to understand whether a low percentage of outliers should be used to assess the security levels and also from from these findings and discussions we find that that most probably probably a lot of different algorithms key schedules should be affected by a similar finding if there is leakage for an attacker that is exploitable and with this I would like to conclude the talk these are the contact informations and some references thank you