 Bonjour, my name is Zélie and I work at Google where I lead the security and anti-abuse research team. Today, with Jean-Michel, which is here in spirit, we're going to tell you how we can use deep learning to reduce side-channel attack surface. Before getting started, I would like to point out that the results you are about to see are part of a larger project that we do in collaboration with many Googlers and external collaborators around hardening hardware cryptography to create more secure devices. Side-channel attack is one of the most efficient ways to attack secure hardware because instead of targeting the algorithm, which is usually well understood and well scrutinized, let's say AES, instead it targets the implementation and the interplay with the given hardware. And this is well less scrutinized because A, there is many of them, and B, it is way more subtle to understand how side-effects of code affect a specific hardware and how that can be exploited by attackers. Here is a concrete example to show you how powerful side-channel attack are. Back in 2017, researchers were able to recover Bitcoin private keys out of a treasure hardware wallet by using side-channel attack. They show you that despite the algorithm being well reviewed and the hardware being well understood, the interplay between the two still had some problems and that you can exploit through side-channel attacks. And from this different side, side-channel attack are very difficult because they are very hard to debug and fix it. So even if you know you have a side-channel, it's really hard to know where it's coming from and what you can do to fix it. So if side-channel attack are both very important and hard to debug, it means that there is a room for innovation on how to help with the situation. And that's where these projects come in, and our idea was maybe we can try to develop new technology to accurately pinpoint the code which is available to side-channel attack so developers can quickly isolate it and try to improve it and improve the quality of their implementation and be more resilient to side-channel attack. So that was the idea we had, and then the way we went about that was we proposed to use deep-learning and dynamic analysis and commiser tool to be able to accurately pinpoint the origin of the leakage, which is responsible or which is exploited by a given side-channel attack. And I know, I know, what you're thinking, you're going to be like, oh my god, one more deep-learning talk, really it's all going to be all hype and etc. Well, actually no. This talk, as I promised, is a hacker journey, so we want to make it very concrete. And what we really want to do today is showcase to you our deep-learning tool, which we call called, which stands for Side-Channel Attack Link Detector and how that works in practice. And to make it very concrete, today I'm going to show you how we can use code to debug Tanias, a very vanilla plain implementation of AS, running on a well-known CPU, which is the SMT32F4. So we're going to really see in practice today how you can use the technique we developed to isolate a very clear leakage. And hopefully, by the end of the talk, you will have a good understanding of what the tool is about and why it might be useful if you are working in the field of cryptography and hardware crypto, or if you are interested in the subject. So with this, how are we going to go about that? First, I'm going to briefly detail how Side-Channel Attack works. Then we're going to discuss how AI-based Side-Channel Attack works because we need those to be able to pinpoint the leakage. Then I'm going to deep dive a little bit into what is AI-experimability and how you go about explaining what a machine learning sees, or understand, or how it makes a decision. And finally, we'll bring everything together. I'll talk a little bit about the dynamic analysis part of the project and how we fit all together to pinpoint the leakage and then I'll show you how it works in practice for the target, our Tanias or SMT32. We can follow along by getting a slide at the very least and hopefully link the code by going to elite.net slash code. As I mentioned, the purpose of this talk is to be very practical, done to us on how can you use and how this type of tool works at a high level and how can you use it as a practitioner, not necessarily how you can develop such a technique and how you can research on how to improve it. If this is something you are interested in, we are working on a paper, a research paper, which has all the technical details about the extension technique we use, benchmarking and alternative and all the good stuff. And hopefully the paper will be out shortly by the time you see this recording or will have been already put on archive by the time you see it. Without of the way, what is, let's start with the copying what section attack are. At its core, a section attack is an indirect measurement of a computation result using an auctionary mechanism. So basically, instead of observing directly the result, we try to infer what it is using a third-party way, which is what we call an auctionary mechanism. Such an attack are used in many, many ways to attack a biased target. Obviously, as discussed in this talk, they are used to recover encryption key out of hardware secure implementation. They also use InWebSecurity to perform blind secure injection when you cannot see the return of a secure statement on a secure injection. And then they also used to steal password and pins from secure implementation. And they also use, as I mentioned in the early example at the beginning, to recover crypto wallet product keys. Those are only for example of the many way you can use such an attack, which is basically when do you need to ever write something you cannot observe, such an attack is usually the way to go. Let's make that a little bit more concrete for a use case. So when you do a computation for crypto, what you do is you feed a plain text and you feed a secret key and the algorithm is running on the CPU. And while it's running, we have some leakage. The first one is how long the computation takes. What is not very relevant to AS when you have hardware acceleration? Actually, depending on the computation, the time might change depending on the key. That was mostly used for RSA a long time ago because RSA use exponentiation and when it's not constant time, it can actually help to recover the key. That's one of the examples, but again timing is how long the computation takes. Then we have the one we use in this talk, which is current. Of course, depending on the operation you do, depending on how many registers you load, how many registers you unload, the amount of power consumption will varies from clock to clock. And so that's what we can measure and that's what we can use to infer what is happening. Then we have the third one, which is less used, but it's still possible it is heat. Of course, depending on which part of the, which type of operation you do, different part of the CPU will be used and as a result, some part will be hotter than others. A little bit of arcane, not most rarely used, I think. I haven't seen very much concrete example, but that does exist. Last but not least, we also have what we call extra magnetic emission, EM. And EM is also a very powerful channel widely used to recover public keys. It is with current probably one of the two most used in session attack. Timing being also important as I mentioned, but really current and EM is probably like the two leading technologies in days. What does it look like in practice? So here is a power trace of an AES. And if you look carefully in the middle of the slide, you'll see where about 10 times the same pattern and they do correspond to the 10 round of AES. So you can visually see on the non-protected or very largely protected AES that we can observe the round by just looking at the power trace. If we can observe it as a human, it means there are some statistical information there that can be exploited to understand what is happening. And that's in a sense, this side-effect that we can use to recover an AES key. In no chair how you go about that. Well, you get a CPU, but the target, to do the encryption. And what you do is you do record while the encryption is performed, the power trace using an oscilloscope. And then in the traditional session attack, the state of the art is called a template attack where you basically combine the traces you observe and you make statistical estimates on what it could be. And the statistical estimate will help you to recover your AES key. This is how it works. If you wonder what type of hardware we use, and again, this is what we use doesn't mean that's the best just what works for us. We use a new AES chip whisperer pro and for some of our work, however, not this hope, we also use a PicoScope 6000 when we need faster sampling, when the target is very fast and when there are information. So for example, last year, when we took about scamo, which is a way to do a session attack using machine learning, which we're going to briefly recap in a second, then we do use a PicoScope. For this work, we just use plain old chip whisperers. And again, this is not an ad. This is just happened to be what we use in practice as we want to make this talk as concrete as we can. Now that we have an idea of what a session attack are, let's talk about how you would go about using AI to perform a social attack. Well, this is something we call session attack automated with machine learning, also known as chemo. This is what we did present in depth last year, but let me briefly recap how they work in practice because we're going to need a model that would create using a schema attack to do the explainability and then find out what the leak is. If you want to have more detail by the way about this type of attack, well, you can check out last year's talk. It's available on my website at elite.net slash chemo. I also probably put a link on to Twitter if you want to follow along. And again, you'll have very more detail. I'm going to try to shrink down the clinician as much as I can so you can follow along. But if you want all the detail, then the previous talk. I also want to say this year is different from last year, so for people who follow both, in two senses. This time, last year when we talked about using machine learning to attack hardware encryption, we took the worst case, which is we are doing black box attack where we are the attacker, doesn't have any knowledge about the target and for example cannot have access to the clock because the clock is usually not accessible after when the key is in or the hardware implementation is in production mode. And so as a result, we were correcting trace in an asynchronous manner, which means that the clock of the target and the clock of the oscilloscope were different, which is why we had to use a high sampling rate. In this specific case, this year we are changing the model because this time, it's called is for people who are developing implementation. So we do assume you have the code, you have the hardware target, you can put it in debug mode, and so we don't need to create asynchronous traces. We also have a good idea if you're a developer at what time I start and what time it ends. So you can also create shorter traces. The reason why to do shorter captures is because machine learning have an easier time if you don't capture the whole thing because that means you spend less time when you train to eliminate part of the trace which is useless. So again, this is a white box attacker model. It makes more sense for that work. However, do not try to compare the model you use in this talk, which are easier and smaller than the one in the previous talk where we had a way harder task for the machine learning. So when you're in a black box, the machine learning works harder, which means you have to train more and use more complicated and more deeper architectures. In the case of a white box, when you are really laser focusing on one part of the implementation, here will be the first round. We don't need that. So way session and attack assisted by machine learning works is very similar to the traditional session attacks. As in the previous case, you have the encryption which is running and then you capture the trace. Don't forget as you capture the trace and you store them to normalize them between one and minus one because machine learning actually works in that range, which is not what your traditional oscilloscope will output. And then we feed those traces to a deep neural network and we try to make prediction on what he thinks are the value which can be used to recover the key. And then we combine those to do a statistical estimate and hopefully you get back to your ASCII. One of the advantages of that, as illustrated last year, is that you do not need to do any kind of pre-processing. You can just feed the trace directly and there is less expert knowledge on it so that it's open to place to do that almost automatically. And so that makes it a little bit easier and also it's more powerful than in a sense than the traditional template attack because of the reason mentioned. When you do a session and attack, you do not necessarily directly target to recover the key. You target what we call attack point in the case of tiny AS. There are two points which works really well, which is a sub byte in which is when you explore the key with a plain text and there is also the sub byte out which is when you look at the output of the AS box. In this talk, we're going to focus on one of them, which is a sub byte in, which we know works really well, better on our experience and this is something which is a point. So basically, the machine learning will not predict the key. That really doesn't work when you try that, but instead going to predict the sub byte in and will basically, if you want to do the real attack, you take the sub byte in and then you have to invert it using the plain text or do another XOR and then you get the key and then it can be a prediction. So the target point today is sub byte in. When the machine learning would predict the sub byte in, what it does is you get a trace and it tells you, okay, here is a softmax, almost a probabilistic output of 256 value, which is the most important value, but also what you think is the second best value, so the best value and so forth, and that's what the softmax do. So what you do on how to combine those things, that's why we call it a probabilistic attack, is you basically sum them up using lockdown because of funding errors and then you combine them and hopefully by combining them, summing them you get the most likely value and the machine learning is correct most of the time, so it will quickly converge. Last year we showed that for 10 years on a full trace, we only need four traces, so you can see, you will see that in the specific settings today, where it's even easier, while you need less than two. So basically, three, four traces for simple cases, you get the correct value and you have recovered one byte of the key. What's important to mention as well here is we have one model per byte, so we should have 16 bytes, which is normal input. We have in reality 16 models which are performing one byte at a time. It is easier for the machine learning to predict one byte at a time, so you have to train 16 times. I'm not going to show that on the slide because it's not relevant, if you can wait for one, you can wait for 16. There's some difference of accuracy between the bytes, but that's not too relevant for this talk. Okay. For those fractures, this year we used a hyper-tuned residual 1D convolution neural network. It's different between this model and last year. This model is way more efficient, it's smaller, and I think it's 300,000 points or something, 200,000 neurons, parameters. It's way too tuned to work really well out of the box. This is kind of like our go-to model at this date, which is based on our previous work and testing a ton and a ton of models. The paper, I said last year it's kind of funny, but the paper on all our tests about all the machine learning model will be out at some point. I said last year it will be soon. We have some technical difficulty to make everything reproducible and we have a lot of improvement, but hopefully I'm really hopefully going to test these models and the data that we use to gain our expertise into this will be out and you guys can test it out, hopefully in the near future. As scheduled, you need the 16 models because you need to know what is the commonality between all the bytes to know exactly what is the main source of leakage. So you train 16 models. As I mentioned, the accuracy varies. As you can see, you reach on things so on data, which has not been seen during the training, you reach on things between 63 for the worst one, which I think is byte 4, up to 87% for the best one, which is byte 0s. And again, they're all between that. First code, it doesn't really matter. What you need is to be able to isolate enough examples that the machine learning is correct because those are the ones we're going to use for explainability. We want to know what is the model that is using when it's correct. That's why we don't train more than that. Try to imagine each of them is about, I would say, 15 to 20 minutes. So you do 3 per hour and you have 16 to go. So, you know, that's already about 5 hours of training time. So we don't want to do 20 epochs, which would be completely overcured. And as I said, unsurprisingly, because the 10 years is not protected against sectional attacks and our model is really well optimized we have high accuracy for all of them. Now, the model is good at extracting the key. So we are able to use it and we can consistently recover keys. Now the question is, okay, how does it help us to go back and find where the leak is coming from? Well, this is why you need to add another piece, which is deep learning and explainability. So what is deep learning and explainability? Deep learning and explainability was first developed, I believe, for vision and the idea was I have a deep learning network and it says, in this picture we have a boxer and we have a tiger cat. Now we can ask the question, okay, but why? Does it really look at the cat, does it really look at the dog or does it look at statistics? I don't know, maybe the stripe in the stripe colors of the tail of the cat or maybe the dog have a leash or something like that. So what you want to do is you want to have a way to ask the neural network what do you look at, right? And that's what explainability is about. Being able to say for a model how does it come up with a given prediction? Why for this specific class I'll put one output neuron what did you use as input and what was input matter to you? So it's basically almost inverting the machine learning model if you will. And so we call that explainability. There are many techniques, but the idea is you all the techniques have in common that you feed the machine the model to the explainer then you feed the input you would like information about and then you have to tell him which class you want to have an explanation for. This is why as I explained earlier we need for school to have model which work well not necessarily 99% but at least very well because we need to have example of prediction which are successful because we want to know for a given trace and a successful prediction what to think. So as I mentioned you give it to the explainer the other side you put the picture we had and we say ok why do you believe it was a boxer and hopefully they will tell you well I look at the face of the puppy and it's a boxer ok that's understandable and you can ask also ok how about the cat and hopefully and again real example out of one of the expansion techniques you will tell you well I look at the cat and the reason why I think it's a cat is because well there is a face of the cat but the most important thing is there are stripes as you can see the right part which is the image and you're like ok that makes sense I guess a cat which have stripes is probably a tiger cat but in essence the machine learning is actually looking at what it should was it technique ever useful and the answer is yes absolutely there is this very very famous data set in machine learning for vision and it's called the path called visual vocabulary visual vocabulary and what happened was in the early version of this data set I think one picture in five for horses had a top bottom left so a bottom left name of who took it and what the machine learning learned was not to recognize a horse it was to recognize well that there was something on the bottom left alright so that's what the credibility is for so therefore we would like because essentially what we want to ask the machine learning is given a input and a prediction can you tell me how you figure what is leaking right where do you get information to the conclusion that the correct key or the current attack point well that seems great in practice just to be right in theory and we can see what's going the thing is so I don't tell us how we're going to combine this experiment with the techniques and dynamic analysis to develop leakage right because so far all I explain to you is maybe how we can get some part of the output highlighted that doesn't tell you how you go back to know where the leakage comes from that's all the difficulty of school this event and that's why it took us about one year over a year to actually really know how to get that done is because you need to be very creative on how to combine those things which in theory should make sense to actually get the results you want so let's dip that into how you get there our game plan was fairly straightforward again we start with an explainer we're going to give it our train models and then we're going to give it the trace and the prediction and say ok please tell me of the trace what are the important points for you to make your prediction we're going to call that the leakage map then we're going to also do run not necessarily after but in parallel a target emulator which is basically we're going to run our target which is the given CPU in this specific talk the mt, f4, 32f4 and the firmware so in our case a firmware which is 10 years and we're going to emulate it to be able to know at which every instruction cycle in the ARM CPU correspond which of code right so basically we need to know at what time precise point in time a given code instruction was run and then which code instruction was run right and so with that we can combine both of them we can combine the leakage map according to machine learning at what time the leakage occurred and the emulation which starts at what time each instruction was run to be able to annotate the code with the leakage at the idea in practice that's where it becomes complicated there is of course a lot of techniques here is a print shot here is a figure from one of the recent paper which is called thanks to check for science map which basically we're looking at how efficient is different type of academic technique and you can see some of them have more defined output than others in this specific in our research we tried a bunch of them including a guided grad cam which seemed when we started to be giving the most defined precise leakage and then we tested a bunch of them the idea was which technique would work best for us because we wanted to highlight a very precise which part of the trace was the most important one how you do that well you get the explanation so you run a lot of traces which were successful into the explanation here is the activation map technique then you combine them and you normalize between 0 and 1 to create some sort of a and then you eliminate all the noise and hopefully you get the bottom images which is this leakage map and you can see it's trided here and you can see that some places which are lighter are supposed to be the place where the model is leaking the most so according to activation maps there is I think it was 4x0 the very very early there was a leakage and very very late around the 4000 points so at the end of our traces some leakage depending on the technique you use you're going to get different results the first one we tested is SNR which is not a deep learning technique but is the standard technique used in traditional attacks to detect whether or not there is a leak so it's a very much a very robust way, statistical way kind of like our baseline so the senior to nose ratio tell you that as you can see there is a main leak and there is a secondary leak somewhere in the middle of the trace and then if we look at grad cam plus plus which is one of the latest technique the results are not so clear we have a bunch of different points which doesn't seem to align very well with the SNR or at least they are less different there are as you can see it's in play but not exactly the same and then the activation map looks almost equivalent to the grad cam that was one of the even the activation map look at the output of the layer, the lowest layer this seems very very much the same so how do you benchmark how good these experiments are so the idea is well we have a leak map so what we can do is we can take our traces that we know the machine learning is successful at predicting and then we can decide to use the leak map let's say we move the 4 points or the 8 points which are supposed to be the most important according to the leakage map out of the tracks we can just literally blank them blanking them means put them to 0 or to minus 1, put them to 0 but some idea basically we move the information there and hopefully either the most important part of the prediction then the accuracy of the model which you feel it again should result in aggregate to decrease the accuracy if you blank out the points which are used by the machine to make the prediction the accuracy should decrease so mechanically the best technique should yield the best decrease baseline as I said 100% because we only used traces you remove 4 points why 4 points is because an instruction takes when we capture them with the oscilloscope is 4 points so each cycle of the CPU should be 4 points so if we know that we say let's try to remove the most important cycle if we do it with SNR the technique seems to work it seems we reduced by 57% and 44% if we do the activation map and it was our first very big disappointment sometime in the project last year not last year but like a few months back well doesn't work that well SNR is better SNR doesn't work really well and then if you remember I should use the leakage map almost the same so the idea seems to work in the sense that SNR works our deep learning expandability which is way more complicated and should be way better doesn't so that was a little bit disappointing and so it was like back to the drawing board what can we do and so the way we went about that is like okay let's write our own technique because what we want is to only find the top point so we can probably do something with a very old idea which is occlusion and try to make it a little bit better so I know it seems weird to say okay let's invent a new technique for this specific task but the thing is we are trying to do something very very unique, very very precise we don't want to have the exact region more like a holistic understanding we want to have like top 5 or top 20 points so because our optimization for our technique is different and the type of underline algorithm you want to use is a little bit different we can use occlusion which is literally try to use a window to do that and so skilled explanation technique is actually exactly that it's a hybrid version of occlusion where we start to eliminate the large region until we zoom it down to the small region and then with convolutions convolutive occlusion which is something we developed for this to actually really pinpoint which part of the trace for the region that we think are predictive which of the exact points are the most important and as you can see the traces are way cleaner than the one we had before and they clearly outline leakage also as you can see by 0 and by 7 it is clear that by 0 is before by 7 in terms of leakage which make a ton of sense because obviously 10 years process one after the other it's not victorized code so that would be exactly what we expect okay so we're like okay trace to the code should work right so go back to the benchmark run the thing and voila number are way better or at least better for by 7 and so again so now we have a technique which works better our map is more precise so we hope that the leakage will be more precise and just to give you a visual comparison to finish on that side it's very clear that A the SNR is called basically fine roughly the same region except the region is better defined with code which is good because the SNR is not wrong in general and B we have something which is cleaner which means that we have improved over existing set of the art and also finding something completely out of the protocol model so physical model is more precise it was good and so as I said benchmark shows that in every cases it's called actually outperform everything we tested it's not to say there is not a better way but this is working for us and this is good enough as we will see so we came to favor this thing because it's also quite fast text I don't know about 10 minutes to explain a network now to explain in greater detail how you go from leakage map how you go from model to leakage map the question is how you go from leakage map to code well for that as I mentioned we have an emulator which is based on unicorn and rainbow and basically we run it with a firmware in the CPU and we basically have a state automaton who tries to emulate what's happening during the leakage map but the idea is you want to do a start run the ES, a stop and basically pick up what is in sync with the leakage map and then what happens then is you get mapped ESM so what you get is you get that cycle maps to this point in the trace map that cycle map to this specific CPU instruction and then what we do is when we have a CPU instruction we build a tree and the tree we bubble up the instruction to a given code line using the debug symbol of our firmware the firmware we run both the firmware and we have it in debug mode again we back to this idea that this is a tool for developers so when you test for leakage you can compile with debug symbol because you don't try to harden it we just want to debug it so when debug symbol happens to go back from the instruction back to the line of code and hopefully that gives us an idea of where to map the code so that's the theory but we haven't told you or haven't shown you about this before I do that I want to be on phase 3 about this project the first one is we spend a lot of time talking about the explainability because if we don't have extremely precise explaining technique which is exactly our point which exactly pinpoint what point in the trace is responsible for the leakage we're going to fair the instructions on ARM are 2 maybe 3 maybe 4 cycle long at most not at most but 2 1-2 instructions for an addition it's literally 4-8 points like our margin of error is maybe 1 point but that's about all we get so if we don't have precise mapping then if we map let's say 10 points ahead or if we have windows of 10 points it's meaningless for us because it might be 3 instructions and those instructions may belong to different line of code so basically your analysis is completely botched at the same time we need to have an emulator which is also single cycle precision because what happens is if you do not take into account if you say pipeline flush if you don't take into account the CPU pipeline size and things like that you get it wrong because you're going to shift everything by let's say 1 cycle for each addition then your whole trices is completely shifted and then even if your leakage mapping is good you get somewhere in the code which is not relevant so you need cycle precision emulator cycle precision single point precision explanation so you need something extremely precise this is very very much a precise work and then on top of that you need a bit of computation again as I said you need to generate about a 1 million data points something like that and then even for the explanation time we use 60,000 trices you need 16 models as I mentioned you can shorten the time of course by using a good model who converge very quickly you need to generate 16 explanations for all those models in your trace and then you need to map everything so with our optimization that will take you a day or so of work and of course as I said it is parallel to the board because 16 models and 16 explanations can be run on distinct CPU so you can make it 16 times faster so that's really good because we want to use that as a fast iterative tool for developers alright, so at that point he gave me a long speech of why it's really hard so probably they failed and it's really really hard because emulating a CPU is hard and I'm telling you it is true that we have a perfect emulation of CPU I think we have a very precise emulation of the instruction we need for AES in particular one thing we don't have a disclaimer if we don't have implemented mapping for for Divide why is because division is actually takes a lot of cycle and a very different range of cycle on ARM CPU so we don't really know what's there so that's only working for now for AES in full transparency that being said if we try to apply what I said to our model what we expect to see in the theoretical sense is we're supposed to is a model that gets insubbed in then it must exploit something in the advanced key because advanced key is where you do the key extorts the plain text so it must have most of the main visor so it's a very cool thing and so what we do to verify that what we said it works is to actually try to verify that and so that's what the schedule looks like it's a terminal thing you basically run it and at the end you spit out this 3 which map cycle instruction which is not displayed for visibility to code line which is basically the numbers and then I filter everything which is not leaking what this mapping tell you is yes the main leakage is on line 213 of advanced key so that's promising it also have interestingly enough a secondary leakage which is later on into the Cypher functions so what is the line 213 right well the good news is it's exactly what we predicted this is exactly the line in the whole code that you can find on github which is exactly where the key is XOR with the plain text so the model and the score in general really clearly is using what a terrible predict which is there is a leak in that specific line because they are doing just they are sending the value of the register there is some assignment sorry and so this is what is so that's a success that's what give us confidence that what we do works in practice it's really giving us interesting result I will not claim it works in every case I'm sure that with more complex implementation like masked AS or more complicated security the result might be drastically different as I said our millators do not fully emulate all the operation you can do on ARM there is still a lot of uncertainty but however it works I think it's a very promising step towards the right direction of having tool who go back from leakage to exact line of code as far as we can tell the first time it has been done back to the secondary leakage I don't have a good explanation for it the best thing I can come up with today is that it probably when some of the register are unloaded and so this is where it starts to do the mixed column so maybe that's what happens is it unloading some of the registers and then we can go back we need a bit more analysis for that but basically it will be interesting to know why there is another leakage so hopefully today I will show you how we use KADL to automatically isolate the normal code and show you how it works in practice and show you concretely what is the benefit of the tool and really our hope is this type of tool we keep building it back from the community to build something which will empower people who develop secure hardware to quickly figure out and patch where the leakage are coming from so we can develop stronger crypto in an easier way and faster iterations so we all benefit from stronger more secure devices and to take a look at the tool as we discussed last year machine learning is a way to automate session attack and you register it with it so it's really one of the most it's at the forefront of session attack and this year we flipped the use case on its head which is really what was in terms of the project from the onset two years ago which is to try to use all those knowledge to actually have developer building better tooling for them to reduce the cost of developing secure implementation and make them better as I said this is a very very new field a very exciting field with a lot of ideas, a lot of energy around it and it can really use more people interested in it so if you have some interest in crypto a little bit of machine learning it's a great time to get in and work with the community on this type of ideas thank you so much for attending this virtual talk I wish it would be in person I'm going to miss Defconn as you will probably do I hope you will wear full up and keep up with what we are doing we try to publish as fast as we can we will do some delay to provide you information about what we do on session attack on the website hopefully we will have an official project website in the future as well thank you so much for listening to this talk and then do not hesitate to reach out on twitter or by email or any other means happy to answer questions bye