 So, you're all expecting a talk at the quantum session, but as already announced, this will not have much to do with quantum or post-quantum cryptography, but if you want to be a bit in the stain in that area, I will try to explain what white box crypto is, it's related to secure software, and try to think, because not many people have looked actually into this, how we can turn the post-quantum crypto proposals into white box solutions, and that would be a fantastic research area. All right, so this talk is based on work with Charles Houbin, Will Michiels, and Phil Teube, all at NXP. At the time we worked on this, and currently both Charles and Phil are at Quark's lab, and our paper was already presented this summer at chess. So what is white box crypto? In order to understand this, let me try to give an overview, when we talk about crypto, we often talk about, you need to understand who is the attacker, where is this adversary, is it internal, is it external, when you think of internal, it can be the user, it can be a virus, and what is realistic for your particular use case? So the old way of thinking about this is the black box model, so you assume that the end point are trusted parties, and the attacker observes data being transferred. So this is from the, let me call it the 80s, and then in the 90s, there was this new model, which people refer to as the gray box model, it's related to hardware implementations, and imagine you have a smart card, for instance, with your crypto algorithm running on it, it was shown that if you measure, for instance, the power or other external information, meta information about this implementation, while this running, yeah, you can use this information to extract the private key material used during the execution of this cryptographic algorithm. So then we come to the white box model, which is related to the gray box model, but it's not related to hardware, it's related to software execution. So now, for instance, think about a cryptographic algorithm running on a device you own, but it's implemented in software. So an easy example, for instance, is a mobile device. And again, we assume that the adversary can be the owner of that device, so it can even be the user of the device, and still we want to protect the private key from being extracted, even by the user running this cryptographic implementation. So, and this setting where you want to, among other things, ensure that the cryptographic key cannot be extracted from the software implementation is referred to as the white box attack model. So why are we interested in this white box attack model? Who is actually using this? So this was originally proposed early 2000s in a setting of digital rights management, and think here of streaming content from somewhere, for instance, to your setup box. And then the party who is streaming the movie to you does not want you to have the key which can decode this movie because then you might be able to give this key to a friend and then he can watch this movie as well. And then there was more or less a decade, not too much attention to white box crypto, until a couple years back when it was a renewed interest in this technology really after the introduction of HCE. So HCE stands for host card emulation. And the idea behind this is that it emulates in software your NFC, so near field communication. And the idea is that it replaces the secure element or it emulates the secure element in software. And this is, for instance, in practice used that you can pay with your mobile phone or take a train or any other transit. And in practice, how is this cryptographic key in this implementation then protected? Because why do you want to protect this? If the user would have this cryptographic key it could, for instance, do a rollback attack which means I pay my fare for my train, I extract the key and I just upgrade to any other amount I have or I rollback the data I had and then I have the previous fare and I actually didn't pay at all. And how this is done in practice is with this, then you are in this white box attack model and if you have a cryptographic implementation secure in this model people call this white box implementation. And we see an increasing and increasing demand of this in practice. So in 2014 FISA MasterCard announced their support for host card emulation and in these payment protocols if you implement them in software it is a requirement that you protect it with white box cryptography. And according to the studies we will only see an increase of these HCE solutions in practice and phones and other mobile devices which actually support this technology. So in practice what do they actually protect? It's mainly symmetric crypto so we're talking about AES and triple desk and how these keys are really protected. Already in practice if you have a mobile phone for instance not only payment but also the apps which are allowed to install from your play store or any other app store you have on your phone. It's very likely that this is protected with white box cryptography. So when you think about this how would you actually try and solve this problem? What should we think about? Why do normal security cryptographic implementations in software not work? Because it was already shown actually before the invention or the introduction of white box crypto by Shamir Phansoma that if you just load your crypto key into memory and you would just scan your memory and look at the location with the highest entropy that with very high probability this is the location of your cryptographic key. And then you can just dump it, extract it and then you have extracted the key. Another easy way how to extract the key is with a technique called S-Box Blanking Attack. So you just have your implementation of for instance AES. You just replace the S-Box with all zeros and then that gets xord in and you just the implementation outputs the key. So we need something more advanced. So then of course the question arises is a white box implementation even possible? The answer of course is no because if you want to build an ideal white box AES implementation you could just create one big lookup table for one specific fixed key but this will not be very practical risk. Even modern mobile phones don't have this much storage. In practice what people propose so in the original paper in 2002 by Chao and others and they propose the technique where you replace every algorithmic step in the algorithm in this case of AES with a lookup table and then the goal is that you put you try to obfuscate these lookup tables by putting input and output encodings on calls to this lookup table. So on the right here you see a nice overview how then the flow of the algorithm would look like and then this already gives rise to much smaller implementation but still orders of magnitudes larger than the original AES and their proposed solution was around 700 kilobytes and you actually didn't compute anything here it was just a sequential series of table lookups in the hope where it was fixed for one particular cryptographic key in the hope that the attacker is not able to deduce any information about the key actually used and partially stored in these lookup tables. In practice however so in the remainder of the talk I will be discussing how to extract the private key from a white box implementation but in practice you would use much more than just white box. I just wanted to tell you to give you a bigger overview in practice people apply code obfuscation, anti debugging just to make the life of the hacker more annoying and different platform binding techniques which all serve different purposes. Like I said if you want to have anti rollback protection or something which is called code lifting you want to protect against these types of attacks as well. So code lifting for instance is the simple attack that you don't want to extract the private key but you just copy because it's software you just copy the entire software solution put in another phone for instance and if you run your cryptographic algorithm you essentially have copied the private key because it was embedded in there and you get the same functionality. So if you want to protect against these types of attacks you need other types of counter measures. I will be solely focusing on extracting the private key from the implementation. And last year at your crypt there was a really nice overview talk by Christine Colbert about these other techniques related to obfuscation and how attackers and people who try to protect these things how that works in practice. So it's good to state that all efforts in academia to build white box implementations have been broken. So it's completely unknown how to build a secure white box implementation of for instance AS of all the standardized approaches. But how do these attacks work in practice? So first of all they were very white box specific. So you need to know exactly what approach was being implemented which encodings were put on what tables which Cypher operations were exactly implemented where and in which set of lookup tables. And if you knew this then you could reverse engineer the code because you could assume that they would put some code obfuscation on top of it target the correct lookup table and then apply your algebraic attack and extract the key. So we studied yeah we looked into a way how to make this a bit easier. So I will try and explain briefly how we took the attacks from the grey box model so how people attacked hardware implementations and how that also applied to this setting of white box implementations. And our attack works automatically. It's very simple. So see for instance we had the chess challenge this year so one of the challenges we created and was related to white box implementation and you could try our two tools which we released and see how it actually works in practice. You didn't need any knowledge of how this was implemented in practice. The only thing you need to know is which algorithm is implemented. So you need to know in practice there are only two choices. Is it DES or is it AES? And then you can put as much code obfuscation on top as you want. We don't care. It's just ignored by our attack. So what's the idea? It's about tracing. So tracing binary. So when you look at academic papers and academic approaches they're all nice and they're open designs. You know exactly what's going on. But in practice what our company is doing they don't specify at all their algorithm and you don't get the first code of course although that should be possible in this attack model but in practice you just get a binary blob which you can inspect. And then our initial idea was let's try and collect information using dynamic binary instrumentation tools and for instance the popular tools for this are PIN for the Intel platform or Foggrind which lots of people use for debugging or memory leakage detection but actually it's a much more advanced tool which can do much more things. So we wrote plugins for these tools and we released them as open source which allows you to trace the execution of the trace the software execution and what do I mean with this? It traces all the reads and writes into memory. So all the memory locations or the instruction locations. Then we wrote a visualizer which visualizes these reads and writes and then we're going to use these traces of these so the other memory accesses and try to find correlations the same way as you try to find correlations in the greybox attack model. So yeah we wrote plugins for Intel PIN and for Foggrind and we were especially interested in Foggrind of course because that supports the ARM platform so that means mobile devices. So how does just to give an example how does a visual trace look like? So here you so this was inspired by a tool as Quark's lab so the time is on the y-axis from top to bottom and on the x-axis you have the whole range of the memory addresses and the different colors is either an access to an instruction memory read write or read and write. So this is a typical picture when you execute a secure software crypto implementation. So why do we want to use this because our attack only needs one piece of information and that is what kind of crypto algorithm is being implemented and like I said in practice that it's either AS or DS so here for instance you see a trace a visualization of a trace of white box implementation and the actual crypto is just the tiny bit on the bottom and large on the right and there you can clearly see nine blocks nine times four blocks so this is a hint that it's probably AS because the 10th round this is slightly different so you see this pattern and then when you have your guess it's AS you can mount an AS specific attack but what if the white box is a bit smarter and it has completely unrolled its algorithm you would just see a straight line like this and of course this will not leak any information then you don't look at the code but you just look at the data so if you just look at the data pattern how it fetches things from RAM you would see one plus 15 nice lookup tables it accesses so that means it's probably DS and then we had another nice example of another white box implementation which had also its memory access pattern sequentialized so then it's really hard to tell what's actually going on but look at the far right that's the stack and it turns out that it's really hard to hide information or access patterns on the stack so if we zoom in on this so this is exactly this green bar on the right if we zoom in you again see a nicely access pattern of one plus 15 so it means that probably the implementation is computing DS okay so once we have decided which algorithm is actually being implemented we could just our idea was let's see if the grey box attacks so attacking a smart card for instance if that works here as well so the naive approach of course would be port your white box implementation to a smart card and measure the power consumption that should theoretically work but this is of course pretty stupid because we have much more in the white box attack model much more powerful attack model and each bit which accesses memory is equally important so the idea is we're going to serialize bits and then you get the equivalent of a hardware power trace which looks like this just values 0 or 1 and it doesn't reveal much it's already visually very hard to identify the multiple rounds in this trace but if you would use auto correlation you would immediately see them but once you realize what you're actually measuring and what you're doing this would be the same as you would in hardware probe the bus so each bit of your bus individually and you would not measure any error so it's an extremely powerful attack and so the hope is of course that you need much fewer traces and it's much easier to extract the secret key compared to the attacks on hardware implementations where there is inherently much more noise and you cannot measure the individual bits that easily so we went online of course and we try to collect white box implementations which were publicly available and we just said let's check if this actually works and to our surprise it actually did work something we did not expect from the beginning so the first implementation online is from Brecht Weisseur he put his white box implementation online in 2007 so it was couple years later already broken by one of these algebraic attacks and after actually finding his implementation back on some internet archive that was most of the work it took only 65 traces and the traces just running the software implementation which takes less than a millisecond and then automatically our tool would just collect this trace serialize it and run a standard DPA attack and the secret key was outputted and similar for the other white box implementation so in practice in the hacker open source community these open source implementations pop up in these capture the flag challenges so at HackOU or SSTIC so the middle two so there we only needed 16 traces but we should say that these were designed to be broken in a day so on these hacker events so they put no encodings on these lookup tables which makes it easier for the algebraic attacks but of course also much much easier to find correlations and then there was a master student clean edge who for his master thesis implemented the most advanced academic white box approach which we then used and created a challenge for ourselves and this was based on the approach by Karomi and it uses these dual ciphers that you can represent AES in different ways and here actually we needed a bit more traces initially 2000 which still is less than a second to collect these traces but in the end after fine-tuning the attack to this implementation it was only a few years ago and of course leads to the question what's the intuition why do these correlation attacks actually work and this was elaborated a bit more on FSC paper last year and yeah the intuition behind this is that the encodings which you put on these lookup tables do not sufficiently hide the correlations when these keys are actually used in the implementation so this of quickly because these white box implementations are deployed and used already in the wild so what about counter measures so the most common counter measure in the hardware community is that you are gonna try and create random masks or random delays you're gonna mask values but we're in the white box attack model so we assume that the user has full control over your platform so if you just query a random number 0 because I you can assume I'm rude for instance on my Android phone and thereby disabling the entropy in your counter measure doesn't work anymore so this approach does not seem to be the right path so what about having some sort of static random data in the white box another counter measure is based on threshold implementations which they use in hardware that seems like an interesting approach to go for here as well there's more on the hacker side of things what about detecting if you run in such a DBI framework detecting if you run within Valgrind or a debugger but it seems like in the hacker community there are lots of papers who introduce new techniques how to detect this and then other techniques how to get around this of course so DCA so this attack is not a holy grill you can use large encodings on these lookup tables because then there's no correlation anymore between then and the output but that means you get larger lookup tables and things actually might become impractical too large and too slow in practice and more over the original algebraic attacks will all still work so after we put this online other people so most notably the people from RISCURE they look at this as well independently and they look more at software fault attacks so the other type of attacks we know from the gray box community and that approach was very successful as well and they showed that if you in this white box attack model you just flip a couple of bits in these lookup tables even if there are encodings on top of them it's similar as a fault attack and you can extract the secret key material as well so we released all our software we used so the visualizer the tracer and the code we created to actually perform a CPA attack or a DPA attack because to our surprise we were not able to find any open source CPA tool together with all the scripts for the implementations I showed earlier which we attacked so people could actually can try and do these attacks themselves so if you feel encouraged please come and help and extend these tools if you know of white box implementations which we could try and test let us know we're always interested in extending our tools and adding more expertise or test counter measures for instance so to conclude it's clear that software only solutions become more and more popular especially in the HCE environment and they rely heavily on white box crypto the attack I quickly described is just the counterpart of the DPA attacks from the hardware community you don't need any expertise it's just a matter of you download the tool and you run it against your white box attack if you know which algorithm is being implemented and this of course raises the question that the level of security and especially maturity of at least all the white box schemes we tested is very questionable we could easily break all of them and this gives rise to a couple of questions so for instance asymmetric crypto there are companies who offer solutions for asymmetric cryptography so think RSA think ECDSH but actually in academia it's a completely open question how to do this so it would be interesting to have if people would start to study this in academia as well because in industry they keep all their designs secret and I think there's a need we need a way to measure the real security level somehow like we do in hardware implementations the security of such software solutions so this is just the beginning I would say so probably we will see much more advanced attacks and countermeasures of course and then attacks on these countermeasures in the near future that leaves us with the final question which I don't know the solution to what is actually the real level of these white box schemes which are applied in these HCE solutions which are currently implemented on our mobile phones thank you we have a minute or two for questions hello you mentioned that your tool can be used in the cases where some additional postcation is applied that was not a bit clear for me so did you test it on some implementations of AES where it's like within a group of I know some garbage code that does nothing or you used only implementations where carefully designed to look up tables and do you think that using sophisticated code where 99% doing some completely unrelated to AES stuff can be countermeasure so yes we did try it on code where code obfuscation or garbling of the code was present so good countermeasure indeed is if you put random delays or random garbage at places because then if you want to try to do the correlation it becomes much more difficult but then it's because it's full control of everything you could just see which steps were not used subsequently and then it would be so we tried this and then it was very easy to write a tool which would just more or less align your traces and remove all the information so that is when you include garbage code but when you do real code obfuscation or transformations on the code that is simply ignored because we just execute the code and look at the addresses being accessed and that's the only thing we need so if there is code obfuscation we simply don't care most of the cryptography that we study at this conference or that we discuss here is either designed to protect and empower the user whitebox cryptography does not do this so if you view it like that how do you evaluate working on whitebox cryptography from a moral standpoint it's a very good question indeed so it does not protect the user it's really protecting the implementation or the entity providing the implementation I don't know morally or philosophically how one should categorize these things it's a good question so in my opinion I think there is a use for whitebox implementations for sure because how else would one try to protect if there is no hardware secure element or something available how would you protect your, how would you want to implement for instance a payment solution in software so there is a need for whitebox crypto there are companies that are doing that by the way there are companies that are selling whitebox crypto to protect credentials and keys for you on your mobile they're crap but they're doing it I was only going to mention that there are other applications here like if you don't have hardware and you want to build an ATM or some other machine where the owner of the machine and really in some sense the user of the machine has a legitimate interest in keeping it secure because you don't want someone to sabotage the ATM and steal all the money out of it but for ATM it's exactly for ATO in most use cases it's often hardware but I agree there are lots and lots of other use cases