 Welcome to my presentation on Leakage Resilient Value Comparison with Application to Message Authentication. This is a joint work with Christoph de Braunig. Typically when we want to prove security of a scheme we consider black box security. So we've got a certain mode, for instance counter mode based on AES or any other mode. And then we consider an attacker. And this attacker can make queries to the scheme and then it gets certain responses. It can make a certain amount of queries and every query comes with a response. And in the end the attacker has to make a decision or a forgery. In practice, however, there's more going on. So if you implement the scheme, the scheme could have very good black box security. But if you implement the scheme and there might additionally be leakage. This could for instance be power consumption or electromagnetic radiation. And this leakage could potentially help the attacker in getting extra information about secret data, such as a secret state or a key. There are two ways to mitigate this problem. One way is protection at the implementation level. The idea is that you take a very efficient scheme, a very good black box secure scheme. And once implemented, you implement it using masking or hiding. In this way you kind of make sure that the attacker cannot get any useful leakage. Typically these masking approaches are designed specific and they could be expensive. The alternative approach is protection at the mode level. In this case, the mode is made in a slightly more involved, slightly more expensive and inefficient way. But in such a way that when implemented, it never gives or barely gives any useful leakage to the attacker. And the difference between these two approaches becomes very clear if we look at permutation-based message authentication code. The most efficient way of doing permutation-based message authentication code is undoubtedly the full state keyed sponge. And here you see a simplified picture of this full state keyed sponge, FKS, and the idea is that we take an ambit permutation and then we glue together the key with the message to get the first state. This state is then permuted to get a new secret state to which the second message block is added. You permute the third message block up to the last message block. You make one more permutation calling, then you truncate to get a sufficient tag length, a tag T of a desired length. And this is an extremely efficient scheme. Most importantly, you kind of compress ambits at a time where n is the size of the permutation. On the downside, it doesn't get any mode-level protection against side-channel attacks. So this means that when you implement this, you need to have implementation-level protection. You need to protect the permutation P. And note that in particular, you have many secret states in this evaluation. So the state gets initialized with the key and the message. This is a secret state. The attacker should not learn the key. Then you permute, you get a new secret state and if the attacker learns that state, it can basically track back and obtain the key. So you also need to protect all the states in the meantime. An alternative way of doing permutation-based message authentication is SUCKS. And SUCKS is a suffix keyed sponge. So it's already originated from Bartoni et al. in 2011 with a very simple simplified version of this. This is the general version that Christopher Knight proved leakage resilient two years ago. And the idea is that the key is only processed in the end. So the first part is a keyless part where you basically plainly hash the key as a sponge using R bits at a time. As a matter of fact, you cannot do full state absorption here because then the attacker might get a collision in the hash part. But this is a keyless hashing part. And only then at the end, after compressing all the message blocks, you blend in the key using some function G. This gives a new secret state to make one more permutation call and then you truncate to get the tag. This key is secure under the random permutation model even if the G is an XOR. However, XOR is not really leakage resilient. But we also proved that this key is leakage resilient if G and P leak up to lambda bits of secrecy per evaluation. And it's important to note that in this case you don't do full state absorption. But on the upside, the number of evaluations of secret states is limited and you barely evaluate the same secret state every time because every time you have a new message you very likely end up with a new state here. And this means that G and P need to be protected in some way. They need to leak up to lambda bits of secrecy per evaluation. But we only need SPA security basically. So we need a lighter protection of these primitives and we still get a leakage resilient scheme. But this is so far so good. This is a message authentication code that we proved leakage resilient. But how does it typically verify a tag? This is just tag generation basically. But for tag verification the typical way of doing this and this is also how it's done as socks is that if an attacker comes with a message and a guest tag in order to verify the tag the typical way is to simply recompute socks in a message to compute the original tag and simply do a value comparison. So you compare T star with T. If they're equal you will turn 1 otherwise you will return 0. But socks is leakage resilient. It achieves very good security even in the implementation setting. But verification might still leak information about T and if the attacker gets sufficient leakage of T it might actually succeed in making a tag forgery. More broadly seen if you look at the leakage resilience of message authentication codes and authenticated encryption schemes the leakage resilience analysis is usually centered around the design of the schemes and not so much about this tag verification. The tag verification is simply left on a scope. It's assumed that this tag verification is then done is protected at the implementation level. This looks rather odd so we do as designers we do effort to make an efficient and efficient as possible scheme that is leakage resilient but then you still need the implementation level protection for the tag verification. And if this MAC or authenticated encryption scheme already uses some protected primitives why can't we just reuse those for verification? And this is where this work centers around. So we do a formal analysis of leakage resilient value comparison. And first I will talk a little bit about the model of leakage resilient value comparison but maybe a bit pedantically I will start with the black box value comparison a security model for black box value comparison. And this security model is rather artificial it's a bit contrived but it gives a good impression of what we want and what we get with leakage resilience. So consider the following security game we've got an oracle O and this oracle is given mu random t bit targets t1 t mu and then we've got an attacker A an adversary A that plays a game with the oracle. So the attacker can make a certain amount of queries these queries are of the form G H A T star and as a response it gets a zero or a one back presumably one if the tag for verification succeeds and zero if the verification does not succeed not succeed and the attacker wins if it ever receives A1. That's a typical security model for black box value comparison and in the black box setting the plain value verification works. So we can define this oracle we can simply take this function as oracle the function gets its input G H A T star and it simply compares T J with T star if this is equal it returns one otherwise it returns a zero and this is what the brackets mean in this case and one can actually prove that in this setting if the attacker makes Q queries its success probability is at most Q over 2 to the power T but this is black box security and in the leaky setting the attacker might leak obtain extra information every oracle evaluation might leak information about the secret targets T and in this case plain target verification does not work it fails because if you take this same plain target verification what we see is that the oracle might leak information in lambda in fact it might leak say up to lambda bits of information about T J for every evaluation and this means that after around T divided by lambda queries the attacker might in the worst case have obtained the entire value T J and in this case a value comparison succeeds trivially so we need to do something smarter we need to have a more sophisticated oracle O and this is what I'll do later but before going to these designs I will make a slightly more generalization of the model and in this model we not only take a random T bit targets but we also take salts more detail again we have this oracle O and this oracle as before gets as input mu random T bit targets T1 up to T mu in addition we have mu salts S1 up to S mu S bit salts which are coupled to T so S1 will be coupled to T1 to T2 etc these salts are also given to the adversary so they need not be unique the salts are in principle in this model they are in principle unique but they need not be you can also take random salts you can actually omit the salts with a slight security loss but it turns out that in many practical applications salts are present anyway in one way or another and we can just as well use them and now the attacker plays the game so the attacker so O is some verification oracle defined typically based on a random permutation or a block cipher or any cryptographic primitive and the attacker can make attempts of the form JT star and it gets this response a 0 or a 1 A additionally obtains leakage for every evaluation and we model this nonadaptively so we consider the following leakage we assume that every cryptographic permutation primitive within the oracle O may leak labda bits of information nonadaptively so this means that if this primitive is evaluated twice on the same input the same leakage will be leaked in addition a plane value comparison of two values so this equals sign with the question mark might leak up to labda bits of information about the values again nonadaptively so if the same values are compared two times the same leakage will be obtained by the attacker and in this model we present two or in fact four schemes four value comparison schemes and the first one is PVP for permutation based value comparison so let P be an N bit permutation this may be a secret permutation for instance AS it may be a public permutation for instance the catch up permutation or the permutation used in chat 3 then we define value comparison as follows so on input of an index J and a guest value T star the attacker wants to compare T J with T star but instead of plane comparison between T J and T star we do a process comparison so we first take the permutation on input of the jth salt concatenated with the jth tag and filled with zeros so we have SJ, TJ and zeros this value is permuted at the same time we take the same salt and the tagged the guest tag T star and we permute it and instead of doing comparison between T and T star we compare the first U bits of the output capital U versus capital U star and these are the two values that are compared and we prove that PVP gives a leakage resilient value comparison function and intuitively this is rather a clean it's a clean way of doing this note that the attacker might learn a leakage so what are the leakage values in this the secret values in this case the secret values that the attacker would like to guess is T J technically and UJ but TJ might leak information but it will only leak information once it's only evaluated once by the cryptographic permutation P it could be evaluated multiple times but this is always under the same salt and the same tag and as the leakage is non-adaptive leak this is always this will always give the same leakage the bottom line is that the attacker learns that most lambda bits of leakage of this T bit value the value comparison might leak information repeatedly the attacker might try different guesses T star and this means that the value comparison between UJ and U star might leak multiple times for the same value UJ so in the end the attacker might get the entire UJ but this is not a problem even if the attacker knows U or UJ in this case to make a successful 4-3 or value comparison must still accidentally hit U by the cryptographic permutation and this happens with a small probability to instantiate we have two options so one of them is to take a public permutation for instance the catchup permutation it doesn't need to be a 1600 bit catchup permutation you can also take a 400 bit catchup permutation the security result holds under the assumption that T the size of the tag, the target values and U the size of the sub-target value are much smaller than N in principle in practice this is not a problem because N is typically large enough if you take the 400 bit catchup permutation you have N is 400 and this approach is actually very similar to an earlier suggestion of the designers by ISAP one of the submissions to the NIST light with crypto competition alternatively one takes a secret permutation B this could be AES with a secret key in this case we don't have any limitation on T and U for instance U can be equal to N we actually get a slightly better bound but on the downside if you take AES with a secret key you have additional secret material namely the key and this also needs to be protected at the implementation level the second scheme we introduce is TPVP for tweakable permutation based value processing and in this case one takes a tweakable permutation which could be a public or a secret tweakable permutation a secret tweakable permutation is basically a tweakable block cipher so a typical example would be for instance the skinny tweakable block ciphers block cipher with an n-bit block size and an r-bit tweak and that either makes a secret variant with a secret key or a public variant by taking a constant key and in this case the value comparison is similar with the difference that the target value are not glued together but instead the salt is input as tweak value to the tweakable permutation the real target value t and the gas target value t prime and likewise TPVP gives a leakage resilient value comparison scheme and the same conditions on t and u apply as a matter of fact it's worth noting that TPVP with a secret tweakable permutation effectively with a secret tweakable block cipher was used in Spook and Spook was one other leakage resilient submission to the nest lightweight cryptography competition so far so good these are rather isolated primitives but we can use them to make a MAC function leakage resilient in its verification and to show this we exemplify this with socks so we took socks from one of the first slides and we glue it together with PVP and this gives what we call STP or socks then PVP in this case socks is exactly socks before this gives a tag and this tag will be the target value in the permutation based value processing function and as salt we take the outer part of the hashing right before in socks you go to the secret part so the salt is taken from the key this computation of socks and it's not necessarily unique but it is sufficiently random and it's also not secret to the adversary so it perfectly fits the security model and we prove that leakage resilience of STP follows from the leakage resilience of socks and the leakage resilience of PVP the downside is that in order to compose this in a black box manner we use independent cryptographic primitives so for socks we use an N bit permutation P also a function G PVP is also based on an N bit permutation it must be independent in order for us to be able to compose the scheme so we take P prime in practice you can take permutations with different round constants for instance but we also have to show that you can also use the same primitive we also introduced half of which stands for hash then function then function so you take a cryptographic hash function and a secret pseudo random function and that composes to the MAC or basically a PRF it's a very well established way of making a MAC function to simply take a hash function on the input and make a pseudo random function evaluation to get a tag but now we use the same function F for a value comparison so the tag goes into the value comparison and in addition we take salt and again the salt comes from the keyless computation right after the hashing so you take the S left most bits and this is the salt the salt goes into F together with the target value and also it goes into F together with the guest value D star and leakage resilience of Havufu is basically the same as before you get a comparable bound, a comparable analysis but the difference is that because we use the same primitive for the PRF part or the MAC part in the PVP part the value processing part you use, you need a dedicated security proof and so to conclude we see that value comparison plays a very prominent role in tag verification for message authentication codes for authenticated encryption schemes and even in this lightweight cartography competition there were two schemes that actually actively thought about this there are many other applications for instance of counter, fault counter measures where you do multiple evaluations of a multiple computations of a value and then you compare the results and our schemes show that you can do value comparison very efficiently in a leakage resilient way by using existing resources there is one point to notice actually and that is that process value comparison the way we do it right now leads to a slightly larger success probability so if you go back to PVP and you see that the attacker has a successful forgery if it either guesses the value dj correctly or if there is an accidental collision here so even if the target value is incorrect the attacker might still get a success here with the value comparison effectively this gives a factor 2 in the security loss this means that you lose one bit of security the attacker has twice as high success probability and we think this is a very modest price to pay recalling that both implementation level counter measures as mode level counter measures often come at a price so leakage resilient designs are often already a bit less efficient we saw this when we compared fks with socks and this is only one bit of security loss and this presentation only gives a very high level idea in the paper you can actually find the exact security analysis also the security assumptions under which the analysis is done and more on the relaxation of the salt this concludes my presentation so thank you for your attention