 Hello everyone, and welcome to this online presentation of our paper on the security goals of white box cryptography. My name is Estuardo, and this is a joint work with Alessandro Amadori, Chris Pruska, and Will Michels. And as a title of our work says, we here deal with the white box attack scenario, and the white box attack scenario we consider software implementations of cryptographic algorithms. And we consider an adversary who might gain access to the implementation code of these algorithms, and who might also be in control of the execution environment of the algorithm. So this gives the adversary the capability of inspecting the implementation code of performing also static or dynamic analysis, collecting input and output pairs, etc. And in white box cryptography we aim to provide security, even under such strong attack threats. So in this paper, what we wanted to do we wanted to clarify what exactly where the security goals of white box crypto would, and, and we wanted to understand them and clarify them as well. And so we would ask ourselves, okay, what exactly should we expect from a white box program, and which security properties should actually achieve. And as it turns out, it, this security properties may vary a little bit, depending on the use case that we're giving to white box crypto. So we started by analyzing and discussing the main use cases of white box cryptography, this being mobile payment applications and the RM applications. And understanding why exactly is white box cryptography being used as a software protection techniques within those, those applications. And in line of this we discuss and study popular security notions which have been presented in the past white box crypto. And this have been presented in the context of the RM applications. And as we see, they might not really be provided the security properties we desire for white box crypto when using it and within mobile payment applications. So in line with this we propose to focus on the security goals of hardware binding and application binding for protecting mobile payment applications for protecting. Yeah, for achieving security against white box adversaries in mobile payment applications. And we provide a security definition for white box encryption programs with hardware binding. So additionally, we also present an impossibility result for general white box compilers so in this case general white box compilers means compiler which from any security metric encryption scheme can generate a white box secure. encryption scheme. So we present we we show that such compilers cannot exist. And I do not talk about this result on this presentation but in case anybody is interested in that we can of course talk about it afterwards. And so, let's start by revisiting the main use cases of white box crypto in practice. For those who are not so familiar with it. So DRM and mobile payment applications. So when white box cryptography was introduced some some years ago, it was introduced within the context of digital right management applications. And in the RM what we have is, we have a content provider, or here a broadcaster here. So this, this provider generates some content, and then encrypts it, and then broadcasts it. So, and then we have a set of users, or a set of subscribers who pay for this for this service. And they, they obtain some decryption or some decoder algorithm, which lets them recover the information that is being being broadcasted. So, in this, in this example, a video streaming platform, for example. And we consider the case that some of these subscribers might want to use might want to misuse their decryption programs. So, so in this case we have subscribers who might maybe want to make copies of these programs and share it with other friends or other people who did not pay for the service. And we want to stop these other people from accessing the content without having paid for it. So, so white box crypto should should somehow help to stop this. It should stop the user from extracting information from the programs that would let let them recover the content, illegitimately, or from copying the program and sharing it around. And a bit more recently, so white box crypto was proposed as a, as a technique for increasing the robustness of mobile payment applications. So mobile payment applications, they serve pretty much the same purpose as traditional credit cards, they. So what they do is they store this limited use keys, which are user specific keys. They store them in encrypted form. And whenever I want to perform a payment at any terminal of my choice what I do is I recover one of these L UK's. And then with this L UK, I generate transaction or transaction request message. And here the white box program consists of this description and this encryption program bound together. And this is an adversary in the form of malware which might find itself within the phone, and might want to extract some information that would let him recover the L UK's and then use the L UK's on any for any payment of his choice or on any terminal of his choice. So here we've revisited this to use cases we might go back to the to the main question of what are the goals of white box cryptography and it might be, it might be that we've. So some of us might heard different answers to this question. And here I discuss a little bit why there might be different opinions in this so, so one, one thing we hear frequently is that the goal of white box crypto is, and cryptography is about hiding the key of a cipher. And this is a natural line of thought because giving the fact that the adversary gets access to an implementation code of the cipher. Then it's, it's, of course we need to hide secret information like the description key for instance, because otherwise if this key is leaked, then we cannot expect any further security properties from this program. But we should keep in mind that that a white box program should still besides, besides hiding the key should also achieve basic security properties that we wish that we usually wish from encryption programs for instance, one wayness or confidentiality, for example. So another, another, another answer we might hear sometimes is that a white box crypto is about hiding the key of as implementations. And, in fact, this is this is a very difficult task and it's a very important one, because as is widely deployed and also in the, in the use cases I mentioned before it is as what's actually being used for for decrypting or encrypting. And, and we have seen based on some evidence, like for instance based on the white box competitions that are hiding the key of as implementations is indeed very difficult. So, however, we should keep in mind that white box programs are also susceptible to code lifting attacks or redistribution attacks. These are the attacks where an adversary simply copies the complete white box program and then runs it on any device of his choice for whichever purposes he wants. So the DRM use case we have this case where the users simply copies the complete description program shares it wherever he wants and without extracting any information from it. And other users are able to recover content. And if we go back to the, to the use case of mobile payment applications we see that here code lifting attacks are also a threat, because an adversary might simply copy the complete payment application with the LU case, and then just run the application to recover the LU case on any device of his choice and any payment terminal office choice so for mobile payment applications. So this program should also achieve security against code lifting attacks. So, I'm going to talk about a popular mitigation techniques against code lifting attacks that were presented in the past within the context of white box this being traceability and incompressibility. So, I will describe these two properties in a bit but here, here, I wanted to show that this based on these examples that we have several works presenting security definitions for incompressibility and traceability and also constructions. And it should be noted that when these, these two properties were proposed, the main use case of white box crypto that was used as a motivation was DRM applications. So we might ask ourselves, okay, are these properties also useful for protecting mobile payment applications. So let's have a look, let's revisit what these properties are about. So traceability is about watermarking and encryption program so in this case a white box encryption program. And we watermark it with a specific tracing key. The idea is that if I make a copy of this program that this copy will also have this tracing key embedded on it. And the idea is that if I find an illegal copy of this program somewhere in the black market, for example, that via this tracing key I should be able to determine who was the original owner of the program. And then I can find out if he's using the his white box program for illegitimate purposes. So indeed this this seems a reasonable property for for trying to control piracy in this sense. But if we go back to the mobile payment applications, we see that it might not really be that useful because. So first of all, the owner of the payment application is a is an honest user who wants to protect his, his L UK's here to protect his, his user specific secret information. And, and yeah it's clear that that the owner of this application is not going to make illegal copies of it and share it around because he doesn't want anybody to, to recover his L UK's. So from this point of view, it doesn't seem like traceability is really necessary for mobile payment applications, or at least not in this way. So, now we can talk about incompressibility and incompressibility is about making programs a very large size. And as soon as these programs are compressed or fragments of the programs are removed, the program should lose its functionality. So here what what do we do is from a conventional encryption scheme or encryption program we derive an incompressible white box encryption program of very large size. The idea of having very large size programs as a mitigation technique against code lifting is that such very large size programs should be difficult to transmit over the network. Because it should take a very long time to do that and this should make it very difficult for an adversary to perform a code lifting attack. And when looking at the mobile payment application example. We again seem. We can see that this seems to stand a little bit in contrast with how we are aiming to design applications running on mobile mobile devices. Right. We're usually trying to to design them in small sizes and so on and of course, a white box program is not going to be small size but it seems a bit contradictory to design the program on a very large size on purpose. And moreover, a very large size program which is difficult to transmit over the network is going to be difficult to transmit over the network. Also in the case that the honest user is downloading it. Right. So it's so the distribution the legal distribution of these programs. It's also going to be affected by by its very large size. So in addition to this, the property of incompressibility unfortunately does not capture any further security properties that we might want from white box programs. Besides of course in compressibility and security against key extraction. So based on this we propose to focus on the properties of of hardware and application binding. Now I explain shortly what these properties are about. They're a bit intuitive from the name. So hardware binding is about having a white box program which it's should only be executable in one specific device. So the idea is that whenever I try to perform an encryption. I should check if I am running on the specific device. So in this case, the device is identified by this delta value. And if it is, then I should output Cypher text should generate the Cypher text and if not, it should just output an error message. So, so if I try to run a copy of this program on a different device should always output an error message and application binding is a bit similar in the sense that the encryption program should only run on one within one specific application. And more precisely I should not be able to separate this program from the application. And so this can be useful in the case that the application is performing authentication operations for instance, it should try to authenticate me asking for a password, for example that only I know. And then if the password is correct, then the encryption can take place. So, so this we consider both of these properties useful for white post cryptography. And we present the definition of hardware binding for application binding we face some issues when trying to define it, but I will talk about that later. But yeah, first I will explain how we define hardware binding so first for defining hardware binding we follow the approach presented in this work titled security reductions for white books key storage and mobile payment. And in this work the authors present a security definition for white box PDFs with hardware binding and also for a white box mobile payment applications with hardware binding. And they define security in combination of a hardware module. So we follow this approach, we also use a hard the same hardware module for defining security of white box encryption programs. So let me explain here how what's hardware module is about. So, so we consider a hardware device. So we have this hardware module, which is secure against white box adversaries. So, here we have a secure master secret key hardware master secret key. And whenever we want to generate a program, a white box program that should run on this hardware, we query the hardware with a label value which identifies the program we want to generate. So we use label value and based on the hardware master key, we will generate a hardware sub key. So, then we, we will communicate this sub key to the entity that is going to compile our white box program so we communicate this securely. Then we will compile this white box program based on the symmetric key that we will use for encryption and based on this hardware sub key. And this will generate the hw which is the white box encryption program and acquiring algorithm. And yeah, the query. I will explain a little bit more about the current algorithm in a second, but the idea is that for acquiring the hardware, we will generate a query value based on the message we want to encrypt. So, now that we have the encryption program we can run it on our device. And whenever we want to perform an encryption, we will first generate the query value. And then we together with the label we will query the hardware. And then the hardware will generate a response value based on the query and on the label and on the master secret key, my hardware master key. And it will, it will give back this response value the sigma. And then our, our white box program should check for the validity of this sigma and, and if it's valid, then it should output should output the, the ciphertext C. And the idea is that for a valid sigma value, our white box encryption program is functional equivalent to to an encryption algorithm run using the key K that we use for compilation in the beginning. And the idea of having a the querying algorithm is that we should recall that in the white box attack scenario we usually have an adversary who is capable of intercepting the values that are coming to that are coming as input. To the white box encryption program. So the idea we want to have a we want to have a process on which for each message that we want to encrypt, we should generate a different querying value, and thus also a different response value. So, if an adversary intercepts the sigma the, the response value, he can only use this response value for, for encrypting one specific message. So, so he cannot just copy one intercept one sigma, and then copy the encryption program, and then use it for generating any ciphertext he wants it will only be useful for generating one specific ciphertext and yeah corresponding to one specific message. So now I can, I can explain you how we define the security for white box encryption. So, what we do is we give the adversary the white box encryption program and we give him also the query algorithm. And we give him access to a hardware Oracle, which generates responses. So this gives him this gives the adversary the capability of experimenting a bit with the white box program. Right. So, and then the adversary continues to play distinguishing game with an encryption with an encryption Oracle so he queries it with two messages. And then the Oracle based on a on a coin value will either either encrypt and zero or m one, and then return the ciphertext. So, so, yeah, the adversary should not be able to distinguish which one of the two messages was encrypted. But the big difference here with a traditional left or right game is that the adversary can only query using messages that were not used for. Sorry, sorry, the adversary can only query this Oracle this encryption Oracle using messages and zero and m one, which have not been used for querying the hardware Oracle. So, so the idea is that the adversary is trying to. So, so the adversary should then obtain a ciphertext, and then he should try to, he should try to distinguish either based on the ciphertext itself, or by trying to run the encryption program without using the hardware. And yeah, so so we capture the scenario where the adversary is trying to make himself independent of the hardware. Yeah, and it's similar with a decryption Oracle that we see below there at the adversary queries it with a with a ciphertext and the nonce. And then we first recover the message corresponding to that ciphertext and if there haven't been any queries to the hardware, based on that message, then the adversary proceeds to play this is distinguishing game, where if the bit value is one, then the the Oracle returns a zero, and if the bit value is is a bit value is zero, then the Oracle returns returns the message. And so, so, that's how we define the security of books encryption. And just to wrap it up, I explain here what are some challenges that we face when defining application binding. So, so first of all, it seems a little bit difficult to define exactly what is an application and when defining security for this we need to consider all the things that an application might do. So an alternative we thought about is defining security for specific applications such as these applications performing authentication operations. However, there we also faced some issues. So, so the idea is that a user authenticates himself with some password or some fingerprint for example, but we need to recall that this values in this case are unique, and a white box adversary might be able to intercept them. So, so in this case it's difficult to to have a consistent definition, because there's always the possibility of the adversary intercepting that one value, and then and then running the white box program. So we thought about having a definition where the white box adversaries a little bit weaker so where he is not able to intercept the value. But here we also faced a couple of issues because so first of all this this was a bit inconsistent with how we usually consider the white box adversary. But second is the fact that in order to define security we need to consider long enough inputs right long enough passwords because otherwise the adversary can just brute force them. But when when we're considering such long enough inputs, then we might as well just consider a key less white box implementation where the user stores the key somewhere secure and whenever he wants to perform an encryption or decryption he just provides the key. So, based on these issues we thought we decided to not present a security definition for application binding in this sense. So now just to conclude the talk. And so yeah so as I recall white box crypto needs to achieve more than than only security against key extraction. So, of course, that's a base security goal but it should achieve more like mitigating cold lifting attacks. And we believe that how hardware binding is a is a central security property that white box programs should achieve. And as well application binding we find very useful in real life applications in practice. However, it's a bit more difficult to define formal. And with this I finished the talk and I thank you all very much for your.