 Okay, hello everyone and welcome to the presentation of our paper titled security reductions for white box key storage in mobile payments. My name is a store though, and this is a joint work with Chris bruska mark fishling Christian Janssen and will Mikkels. And in this work, we're going to be focusing on the white box attack scenario. And in this attack scenario, we consider software cryptographic implementations with embedded secret keys on them. And we consider an adversary who gets access to the implementation code of this cryptographic algorithms, and the adversary is able to inspect the code. He's also able to modify it is able to control also the execution environment of the code, and he can collect input output pairs for instance, and perform dynamic and static analysis. And so in white box cryptography, and we aim to implement cryptographic algorithms in such way that they remain secure, even in the presence of such strong adversaries. Okay, so white box crypto for mobile payment applications. So 20 years ago, white box cryptography was introduced in the context of digital right management applications. And in the area and what we have is we have some service provider, which broadcasts some some content or some information in encrypted form. And then we have a set of subscribers who are allowed to recover this content. So more concretely, the subscribers get the encryption program which lets them then the crypt and those recover this content. And here, white box crypto is being used as a, as a means to mitigate attempts of piracy on this program programs. So like to ensure that only users who actually subscribe are the only ones who can recover this content. But then, in a different context in 2015, Android introduced host card emulation, which would allow the application processor of mobile phone to use near field communication. And then here vendors of mobile payment applications so an opportunity of implementing such applications completely in software. And so, so as we're going to describe in a bit more detail. This mobile payment applications they use the NFC and the NFC chip for communicating with a payment terminal. And thus, implementing these applications in software only had the benefit that it would increase their deployability so so it would be easier to distribute them. But also that the vendors could implement them without having to think too much about the phone. And that was going to be using them. So, yeah, so any phone running on Android would be able to to use such applications or to run such applications. And white box crypto was then proposed from the beginning as a software counter measure technique to protect this mobile payment applications. And to look at it in a bit more detail this the payment applications. They basically serve the same purpose as a traditional credit card so so if I'm in a shop or anything and I want to make a payment then with this application I open it and then I come to the point of service to pay. Yeah, and then I generate a request message so so more detail what happens is that the application stores some limited use keys in encrypted form. And this limited use keys are specific for the owner of the application. And then every time I want to I want to make a payment. I decrypt one of these keys, and then I use one of these keys for generating a request message. And so this this key also authenticates me as as the as the owner of the application. And, and so what we usually white box here is the description program and then, yeah, and then also the encryption program using the limited use key. And why is white box being used here. So yeah we consider the case that the mobile phone might be infected with a malware, which is the listening and observing the processes within the the operating system. And so the idea here is for the adversary his goal is to try to recover an L UK and then use it by himself use it independently to perform a payment. And then to do this the adversary. For instance, he could try to derive the value of a secret key from just observing the cipher text. And, or alternatively he could try to extract the description key. And then use this description key for recovering the L UK. And this is this is where the idea came from so the idea is that then using a white box description program should make it difficult for the adversary to, to then extract the key and thus recover the L UK. And, however, there's another attack vector for this adversary that we also need to consider. And it's the case that the adversary might also just try to copy the complete payment application with the encrypted limited use keys, and then run the copy of this application on any any device of his choice, and use it for paying the money where in any terminal of his choice right and in this case, the adversary doesn't really need to extract any any specific information from the application or perform reverse engineering attacks, since he can just run a copy of the software and thus considering this as such white box programs and payment applications in this case need to provide some protection against such attacks which we refer to as cold lifting attacks. In this work, we focus on the property of device binding as a means for mitigating cold lifting attacks on white box programs. And the idea of device binding is that we're going to, we're going to generate a white box program in such way that it can only be executed on one specific device. And if the program is being executed on different device, then the program should be useless. So the idea is that, for instance, for an encryption program if if I want to perform on encryption. I'm going to check if I'm running on the on the intended device. So in this case, the device is identified by by specific hardware identifier delta. And so if I am there, then I will perform on encryption and then output decipher text. And if I'm not, then I should just output an error message. And so in this presentation, it will become quite clear why we we choose to focus on device binding, given that it seems to be the best suited method for protecting against cold lifting attacks for applications running on mobile phones. But I'm not going to be talking so much about why we choose device binding over other methods, which have been proposed in the literature in the white box related literature. But we have this other work called on the security goals of white box crypto, where we talk a little where we make a more of a comparison of these methods which have been proposed as a as a means to mitigate cold lifting attacks. So what we're doing in this work is we present security notions for a white box KDF with hardware binding, and then also security security notion for mobile payment applications, which should be secure in the white box attack model. So we present a corresponding construction for the white box KDF, which is based on puncturable PRS and indistinguishability obfuscation and then also a construction for our mobile payment application, which uses the white box KDF as an integral building block. And so in the rest of the talk, I'm going to be talking mostly about the white box KDF its definition and construction. In the end, I will also mention how we use it within the mobile payment application. Yeah, another one way that I also like to look at our construction is that it can also help understand how white box cryptography with device binding can be implemented in real life. So in real life, you, you might want to substitute the puncturable PRS by more efficient or more popular PRS or PRF candidates like as for instance, and also instead of using I owe you might want to use other other methods of obfuscation. But else the design roadmap is can be pretty much applied for for implementations in real life. And so now we're going to talk a bit more in detail of on how how we see this property of hardware binding. So, so what we assume is that the device where we're going to be running the white box program has some secure hardware some some hardware component, which is not accessible to the white box adversary. So, the white box adversary only sees this as a black box, and can see the outputs coming from it and can also query it. But he doesn't see what's inside. And this hardware and hardware component has some secret key material in it, which is obviously unknown to the adversary. And then we're going to be using this secret key material for identifying the hardware so so whenever we want to perform some some operation with our white box program, we're going to query the hardware and then based on this key material. We're going to obtain a response. And then the white box program should should be able to identify if this response corresponds to the intended hardware or not. And so we're going to get into more details, just in a minute, but I just had this slide. Now, because this is at this point, one of the questions that comes up the most is, if, if my device has some hardware, which has some secret key material and apparently supports the execution of cryptographic implement a cryptographic operations. Then why would I want to use white box trip to anyway right. And as I mentioned before, one of the biggest advantages is that for the designers or for the providers of the applications, and they can gain independence from the phone manufacturers. And indeed, this has many, many benefits. Mostly because not all phones will have a hardware components, which will provide the same always the same functionalities. And then there, there also might be the case that you might need a white box program which executes some operation which is not supported at all by any, any of these secure hardware components. So, for the providers, it's an interesting to be able to design an application which you can share, and then you can be, you can be sure that any user which has, for instance, which has an Android phone is going to be able to use it securely. Yeah, and so additionally, usually, we have applications which perform a bit more than just one cryptographic operation so if you see if you think about our payment application that we described in the beginning. We were first decrypting something and then we were using the crypto value as as a key for encrypting something, something else. And so usually when we access the secure hardware components for performing cryptographic operations we cannot perform all of them in one go but we, we, but we need to access it for each operation we want to perform. And this means also that we need to perform context switch every time we access it. This might lead to some delays. And it also means that some of the intermediate values that are being used in the calculations might be exposed. And so we might want to avoid this in some cases. And so the idea that we have in this paper is that we want to use this hardware as little as possible, but in an in an effective way, in a secure way. So we're going to, we're going to make our hardware binding we're going to build it based on a simple cryptographic operation, which we can assume that is supported by all hardware components, and we're going to use it only once. But then the rest of the calculations are going to be performed by the white box programs. So now we're going to look at how we can define hardware binding. And so the idea here is that we're going to define the security for a white box primitive in combination of a hardware module so next we're going to introduce the syntax of both. And so, as mentioned before, we want to construct a white box KDF. So we're going to start up from, from a traditional KDF, which takes us input some secret key K, and some context value E. So based on this context value is going to derive a sub key here sub key. So as you can see this is a simplified version of our KDF because it just takes these two inputs. And then it derives a key, but the property that we expect from this KDF is that it's output. So it's key should be indistinguishable from random. So it's output keys. And, and what we're going to do is we're going to build a white box KDF which should be functional equivalent to this traditional KDF. But the white box KDF does not take us input the key because it already has the key embedded on it, and it will take us input the context value and then some additional value which is going to be the response from the, from the hardware. So next we define the syntax of the hardware module and of the white box KDF. So now we're back at this picture, where we have our, our hardware and our secret main key of the hardware which was generated at random. So now whenever we want to compile some white box program that should, that should run on this specific hardware, we're going to query the secure hardware with a label value, which will identify this program. And so now based on that label value and based on the, on this main hardware key, we're going to derive a sub key. And this sub key is going to be communicated with the entity that is going to be responsible for compiling the white box program so now here we assume that we're able to, to share this key with that with that entity securely, of course. And then this entity is going to compile the white box program based on the KDF key K, and then based on this main key KHS. And so, as mentioned before, the white box KDF, the compiled white box KDF will be functional equivalent to the KDF. Yeah, but then assuming of course that we are running on the intended hardware. If it's not then then it will not be functional equivalent or better said it's going to be useless. And now when we have the white box already running on the device or on the phone, and whenever we want to, whenever we want to run something or if we want to derive a key, what we do is we query the hardware with the context value that we mean to use, and the label which identifies the software that we're using, or the white box that we're using. And so now, now the hardware is going to generate a response and this response is going to be generated based on the hardware main key on the label and on the context value E. And then this, this response is going to be returned here. And then the white box KDF is going to output some that the right sub key, the intended right sub key. And so for a bit of context you see here, the, so here we describe the operation flow that follows on the white box KDF so. So it's first going to perform this check operation which is going to check for the validity of the Sigma, and it's going to do this based on the sub key that we used for compiling it. And if the check goes through the we will generate a sub key with the KDF. And if not, then the white box will return an output. So now we define the security of the white box KDF. And what we do here is we give the adversary the white box KDF so here he is standing on top of that but yeah this just means that he has access to it. He's inspected and so on. And we're going to give the adversary access to a hardware Oracle. And this hardware Oracle is going to provide him with responses that he can then use for running the white box KDF and then analyzing it. So, yeah, so as you can see here, it generates a response. It has some asserts in the beginning that are going to become clear in a second. Yeah, and then in the main part of the game, the adversary goes on to play an indistinguishability game with KDF Oracle. And so he queries this Oracle, and then value a context value is generated a random. And then if the secret B is set to one, we generate a KDA a KDF sub key based on this context. And if not, we just draw some sub key at random. And we return the context and the right sub key to the adversary. And yeah, so so we say that a white box KDF is secure. If the adversary is unable to distinguish over here. So, now, a little bit on the construction. So, so here on on gray on this gray rectangle. We specify how we construct the operations that correspond to the hardware module or that are running on the hardware. So first the sub K sub K gen this operation that we perform in the beginning for generating the sub key that we later use for compiling the white box. And so what we do here is we just run a PRF and on the main key on the hardware main key and then on the label and base and this way we derive the sub key. And then the response that's going to be used for generating the sigma values is going to run a PRF also on the main key and on the label, and then it's going to run a puncturable PRF on the resulting value and the context value that we want. So, yeah, so once we have the two keys, we can give them to the compiler. And the compiler is going to obfuscate the circuit that we see here, which has the, the hardware sub key and the KDF key embedded on it. And so, as you can see in the beginning, and it's going to, it's going to input the sigma to PRG, and then it's going to compare that to the output of a PRG on the PPRF on K on the sub on the hardware sub key and E. So, so basically what it's trying to do is it's trying to recalculate the sigma and then seeing if, if it works properly. And yeah, and if that goes through then we run a PPRF for generating the sub key. And if not, then then the circuit just outputs error. And then our compiler is going to apply indistinguishability obfuscation to the circuit, and it's going to return our secure KDF. And then it's going to prove the security of our construction. We apply the puncture programs approach from Sahay and waters. And our proof is a hybrid argument over the number of queries that the adversary makes to the KDF Oracle that we saw in the beginning, and the hybrids are constructed such that in the first hybrid. And the game outputs only PRF values all the time. Then in the second hybrid, the first output of the game is a is a randomly looking value, but then all following outputs are PRF values. And then in the in the third one, the first two outputs are randomly looking values, but then the rest are PPRF values, and so on and so on. Yeah, until we have, we have a game where all the outputs are randomly looking values. And then to show that each hybrid is equivalent to each other, we go over a series of game hops. And here we're substituting we will be substituting the circuit that we want to obfuscate by functional equivalent circuits. And so we're going to have a look now quickly at this functional equivalent circuits that we that we see so the first, the first, or the second circuit that we consider. And it's a circuit that is now using punctured keys. Well, the, the first key is punctured, the hardware subkey is punctured on the point C. And, and so now we know that if we run the PRF on the second line, if we run a value E that is equal to C, then we're going to output some, some error in this case, we would have output some error in this case so we add the line in the beginning, where we check if the value E corresponds to the value C where we have punctured and then we check with the PRG, if the PRG on Sigma equals the PRG on tau whereby tau corresponds to the output of the PPRF. And when, when the input is C, the PPRF on the hardware subkey. So, so here we show that the first line on the circuit on the left is functional equivalent to the, to the first two lines on the circuit on the right. Then, for the third circuit, we hard code a value Y, which corresponds to the PRG on tau. So now instead of executing PRG on tau for checking if PRG Sigma equals PRG on tau, we're just going to check directly if PRG Sigma equals pi. And there we see also from from the correctness of the PRG that these two circuits are functional equivalent. Then when we go from the third one, and to the fourth one, we substitute the value Y by a value drawn at random from the set of values with size two N. We hard code also a key and key and key star. And this key corresponds to the key that is derived when the PPRF on the key K so when the KDF basically is queried with a context value equal to C, because now we have also punctured the KDF key. And, and thus this value we hard coded in it for the case that we, and we are giving us input, a value E equal to the punctured point. And so here, we also show that these two are functional equivalent. And then on the last circuit, we substitute the, the second line. So instead of outputting the, the key K star, we output always zeros for this case. And here we can show that these two are functional equivalent, because with high probability, the value why that we chose randomly from the set to end is going to be outside of the image of the PRG. On, on, on Sigma, and those we show that these two circuits are functional equivalent. And it's important to notice that for the circuit C five, and the value this this output value K star is not, is not going to be relevant anymore. For this reason, in the eyes of the adversary, it doesn't matter if when he's playing the indistinguishability game, the KDF Oracle is outputting values that are actually random or values that are, or values that are calculated with the pprf. So, and now we reached the final part of the presentation. And here I will just discuss shortly. So what we do with this white box KDF here we have a picture displaying that so so we are back now to our payment application. And here we have the value pay that's the notation that we use in the paper. And so here what we do is that every time we want to perform a payment, and we need to decrypt an L UK, what we're going to do is we're going to derive a key based on an ID corresponding to that L UK that we want to decrypt. And then we're going to use that key, and then we're going to use that key for decrypting the L UK. And now we can proceed as usual by using the L UK for generating this request message. And the white box KDF is, is only functional in the presence of a specific hardware device. And thus, without this white box KDF this whole construction, this whole application can be used. And thus, the application is hardware bound and also white box secure. So with this I finished the presentation. And I thank you very much for your attention. And if you would like to see more details on the construction of our payment application. I invite you to have a look at our paper. Thank you.