 Okay, welcome here at SHA 2017. This is, I believe, the second slot and we will now have some great information about crypto. Who of you has recently been using some kind of encryption? There are people who didn't. I'm surprised. Okay. Who of you has been using RSA in the OpenSSL implementation or at least knows that he did or cheated? Some of them. Well, Lukas and Praveen will now tell us how horribly broken it is, I assume. They are searchers at RISCure and mostly work on side-channel attacks, for instance, or specifically on RSA. Have a give them a warm round of applause, please. There's a problem with turning on the screen. So we have to wait a second. Thank you. They have some problems. There are some problems with turning on the screen. Okay, so Well, then let's start with the nice part. How was the camp for you up to now? Well, we got quite late. So we just run here. We haven't seen much yet. Yeah, so, well, I hope it will be great. Okay, so maybe let's have a question. Do you know guys what is side-channel analysis? Okay, I didn't hear, but Yeah, there are a few hands. Okay, so what we do mostly we work for a for a lab that does let's say hardware evaluation fault injection side-channel analysis, there will be some more people talking about the other topics. In particular here, we will show something on OpenSSL, on the RSA implementation. This is of course not the It has some counter-majestic against side-channel analysis mainly against all these cache attacks and maybe maybe you are aware they were shown attacks how we're using timing clickage following from cache or all the other things to get the key of RSA from there. We did it using EM and power. Here we will present some results based on power. Okay. Okay so we will talk about how we attack the RSA implementation from OpenSSL. So as Lukash already mentioned, there are some counter measures and even then we could still attack it. So we will explain how we did that. So this was a joint work with three people. That's me on the left, Lukash on the right, and then Rafa is supposed to be here. He'll be back soon. So this is a joint work all of us. Okay to give you a very high level overview of what this is going to be. The attack that we are talking about is called cross-correlation attack and we will explain how it works in general without taking RSA or OpenSSL into frame. And then we will show how the RSA implementation in OpenSSL is vulnerable to this kind of attack. You can see the picture. This is actual setup that we used to break it. So there is a oscilloscope, the power supply, and then there's a small here. This is where we had the OpenSSL running. It's a small 32-bit microcontroller inside. Oh, we will show the setup a bit later. But yeah, this is actual setup that we used. So we already saw some hands raised when we asked, do you guys know about side channels? So to give a very brief overview for those who don't, we know that every embedded device has some interfaces and some of them are intended. For example, keypad to enter, let's say password or any other information or screen to see things. So there are all these kind of our speakers. So these are all intended ones. That means these are provided by the system. But there are also some unintended interfaces. For example, power consumption or electromagnetic radiation. These are byproduct of your system. So they are there. You can't do anything about them. And these can actually be exploited by an attacker to recover secrets. So that is what we're going to show. So these kind of things, interfaces are what we call side channels. Some of the widely used side channels, I think you know a few of them already. For example, time. How much time a particular operation takes. And in terms of RSA, for example, as we show a bit later, but depending on what is the secret key bit, whether it is 0 or 1, the operation that it performs is going to be different. And based on that, you can recover full secret key. If the implementation is not protected. So that's one of the side channels. And then we have power consumption. So this is what we actually did. So we measure the power while the device is executing RSA. And that could leak information and even electromagnetic radiation. So you can put the probe on top of your chip and then measure the EM radiation and then that could be used as well. So there are others like light, sound and temperatures of the many side channels. Then how do we exploit these side channels, right? Again, there are two different ways. One is what we call a passive side channel where we just observe the operations and we don't do anything with the normal behavior of the device. So that means we just see what is the power consumption while it is computing something. Or we see the EM radiation, but we don't do anything with the normal behavior. So those are what we call passive attacks. And this is where our side channels falls in. And the other kind of side channels is active. So there you can actually go and change the behavior. For example, inject fault during the computation and use that to again recover the secret key, for example. So those are called active attacks. And normally they are also called fault injection attacks because we induce fault during the execution. But in this talk, we are only going to concentrate on passive attacks. Which is side channels and in specific only power consumption. Yeah. Okay. To show you how power analysis can be very powerful, let's take an example. For example, you have a card and you need to enter the pin. And only when you enter the correct pin you can log in. Let's say. And you are trying to measure the power while you are doing this verification. So everybody can see this figure clearly. So these are the actual power traces while the verification process is happening. So in the first attempt, we entered a random key, a random passcode. It's four digits. And then nothing happens. And we have this trace. And in the second attempt, so we tried for the first, let's say, this bit. This digit. Sorry. So they are like 0 to 9, 10 options. So we tried all of them. And apparently for 8, the power trace looks a bit different. Yeah. Because this is when you enter wrong one. But when you have the first digit right, then the operation, that verification fails a bit later. Yeah. And similarly, if you get the second digit right, your verification is failing a bit later again. Right? So this will give you feedback about, okay, whether the entered digit is right or wrong. And by measuring the power, you can see, okay, at which place the verification goes right, then you can say that, okay, this is the corresponding digit. And similarly, we can find the third and the fourth. So this is how we can actually measure the power and figure out what are the four digits by maximum how many attempts, 10 times 4. Right? Instead of, if you want to brute force, you need like almost 10, actually 10,000 attempts. But we can do it in 40 attempts. Right? So that's the power of side channels. So this is the verification process. And what I just showed you is called a simple power analysis, because we are just trying to figure out the operations or how the paths are going. We use the exponents of half of size, which is going to be more efficient. But then we have a way to combine them so that at the end, we get the correct answer. So that's another way of computing the same, either encryption or signature. And to implement RSA, the most critical operation is the exponentiation because we are talking about numbers of 1024 or 2048 bits. Or if you talk about CRT, then it's half of the size. That means we have to raise the numbers to such large powers. And this is a costly operation. So there are a lot of ways to improve the efficiency. And if you talk about the basic improvement is what we call square and multiply. Yeah? So here what we do is if the exponent bit is zero, we just do square. If it is one, we do both square and multiplication. So there is a clear difference. Let me show you a bit more in detail how this works. We have the modular exponentiation and the exponent length is let's say L. And you initialize this to your message M. Okay. It's quite straightforward algorithm. You go through every bit from left to right and then see if the bit is zero or one. If it's zero, you just do the square and then return back. If it is one, then you also do the multiplication. So there's clear difference between bit zero and bit one. This can actually be used in a straightforward timing attack because it takes different amounts of time depending on the secret key bit. So there are several sequences of operations, square, multiplication and square. And sometimes you just go from square to square. Okay. I'll skip this. But this is just the algorithm of what I just mentioned. But you can see that these two in this particular operation, the multiplication what we are doing M is going to be same for every multiplication. Because the message M is constant. That is where we are operating on. And if you take the power trace and then try to take two places where this M is being manipulated, you can see a definite correlation. So that means if you take any trace and try to do a correlation on it, compute the correlation on this power values, you see a certain spike when the message M is being used. So that is what we can use to see if the operation was just square or multiplication. And that can be actually used to read out the full secret key. This is actually just a simulation of what I just explained. You have the bits both on the rows and columns. And then when your bit is one, that means the multiplication is happening. You see a certain energy here. And by looking at this figure, you can directly read out the key because this means this bit is one, zero, one, zero, and so on. So just if you compute the correlation on this particular trace, and then you have this picture, and then that's it. You can find out what the secret key was. This is actually a power trace that we collected when RSA is happening. And the exponentiation was basic, square and multiply. And you can already see there's a huge difference between when the operation was just square and when the operation was square and multiply. So there is a huge difference. And then even this can be used to find out what is its particular secret key bit is. That was a very straightforward implementation, as I mentioned. But there exist counter measures. And one of them is multiply always, which as you can guess is going to do the multiplication in respect to if the bit is zero or one. So now you can't really just look at the trace and say, oh, this must be zero, this must be one. So every time you do the multiplication, but you only take the result into account if that bit was one. If the bit is zero, you just discard that result. So that means you follow the same path irrespective of whether the bit is zero or one. But only in one case, you're going to take the result. In the other case, you're going to discard it. So this will make the simple attacks like I just showed not possible because it takes the same amount of time. And same if you see the power trace is going to be similar. Yeah. And here it's a bit important what is the sequence of operation going to be. So here sometimes you have square, multiplication, and square. And sometimes you have square, multiplication, and discard. So you're discarding the result. And then you follow it with the square. Okay. Again, what are the operations that are sharing one particular operand here? Earlier it was M. M is same for every multiplication. So that means when you compute the correlation, it will stand out. But even here, we have a certain value which is shared and that is these two. The S used here in the next iteration is same as the S used here if you discard it. So if you continue, if the bit is one, this S is going to be different when you use in the next iteration. But if it's zero and in which case we discard, this S and this S is going to be same. So again, by combining the power consumption at these two points, you can see a correlation which can be used to read out the key again. So we do the same attack, but now with multiply always counter measures enabled. The figure now will be slightly different. But again, you can see that there are places where you can see a square which is much more like spread across four blocks at least. So in this case, that means there are two operations sharing an operand which is S. And that means the bit is zero. So this, the same attack can actually be used even if you use multiply always counter measure. So to just give a logical conclusion to what I've been telling, you have a basic exponentiation which is binary that can be attacked by using cross correlation. But even if you do a simple counter measure like multiply always, we can still do the cross correlation attack and read out the key. And then Ukash will take over and talk about how the open SSL RSA implements exponentiation. And then we give a full attack path from measuring and then how we actually process these traces and then how we got the secret key out. Okay. So these implementations that were shown here, they are not very commonly used. These are things that used to be used maybe 10 years ago or something like that. It's still possible to see it sometimes, but in open SSL they decide to use different implementation. So this is a KR exponentiation method. So previously as far as I remember in the open SSL, there was some kind of windowed method implemented. But due to the timing attacks and cashed attacks, they decided to implement a bit more regular methods. So target for our fault injection and side channel analysis R&D just to have fun and discover new techniques. It can run at 168 MHz and that's actually the implementation that we will attack. It's possible to clock it at 30 MHz. Did we actually clock it at 30 or at 168? Okay. So here in this case we clocked it at 30, but we also did the same attack. So the problem is exactly what's mentioned is flash waiting cycles. So it may happen that there will be a court jitter when you do some flash caching of instructions. But anyway, we did it also for 168. The misalignment is small. The difference in time. Okay. This is designed by us as the realistic training target. So we have source code. We can modify it and then we know what's happening. So essentially we attacked software implementation. There was no crypto hardware crypto accelerator or something like that. Although I still believe that would be also breakable even then. Actually now when I think about it, even if there was a crypto accelerator, OpenSSL doesn't use it by default. Maybe with some flag settings it's possible to turn it on. Okay. We will use power consumption. So essentially we will measure it at 3.3 volt pin. As far as I remember, it's this one. And then ground are pretty much all these pins. Okay. Here is no need for amplifier. So essentially there are, on the other side, there are some capacitors. So we just removed as many as we could. So the board still works. Then the signal using current probe. I think there is a picture. Okay. Maybe not. Anyway, there is, we are using current probe. We remove capacitors. We will be able to see signal. We will see traces in a second. We used picoscope 3207B. This is a relatively nice model with a lot of memory. So we were able to capture all the execution of RSA. We used some relatively stable external power supply. We also, since we wrote the code, we just generated a trigger on the GPIO pin just before the decryption. So essentially our oscilloscope will be able to, in real time, to know now the RSA is happening. Communication is through FTDI cable. Then again, current probe. That's our in-house hardware. And we used our software risker inspector for acquisition and for the analysis. Okay. Let's, I will just play the whole setup when it's ready. Okay. Sorry. Okay. So what will happen here is that, okay. First of all, there is connected the current probe. So that will collect the, the power consumption will be collected and sent to oscilloscope. So there is just a cable connected. Now our PC first will say to the oscilloscope, now be ready to capture the traces. So then in this moment, oscilloscope starts waiting for any signal from the, from here, from the embedded system. Then our, from PC through FTDI cable, we send a command that essentially says, and performers say on this cipher text. Then the device will start doing its magic. So we'll do the blind link or anything that, that we mentioned before. And then before the, the real operation starts, it sends, it sends the information. Okay. Now the, now please start measuring. Then it, of course, computes everything, sends the response, and the, the, the oscilloscope sends the signal, the digitalized signal already to, to our PC. And then we can observe our trace. This is, by the way, not the trace, not RSA, but probably this. Okay. What sampling frequency did we use? So there are, there are some details about acquisition that we again didn't go into detail, but we have to sample at higher frequency that the target works. In this case, it was 30 megahertz. There are some theories, but rule of thumb, we should go at least five times more. So if it was 30 megahertz, then we should have, should be capturing at least 150 million samples per second. We go a bit higher, so go to 250 million samples per second. Why? Because we have space on our oscilloscope and it's always better to over sample than under sample. Or that's at least what I believe. Number of samples, 170 million for the full operation. So that's, that's quite a lot. It will result in huge traces, but what's important is it's 80 million for the first exponentiation in CRT. So I'm not sure if you remember, but there was DP and DQ in the RSA CRT. And the question is, do we need to actually recover both of them? Fortunately, they are mathematicians. They worked out we don't. We only, we need one. We only do DP. If we recover DP or DQ, then we are done. The second one can be computed based on the public key. So we will roughly speaking need 80 million. Okay. These are some technical details, 150 millivolts. So that's the range for the, for the oscilloscope, how much, how much variation there are. So this is to avoid some issues with quantization errors or we've just setting oscilloscope not correctly. There are only eight bits that the oscilloscope can measure, so we don't want to waste too many of these bits. And how many traces did we acquire for this attack? 10,000. Well, that's, we acquired as many as we needed, essentially. If we needed more, we would have continued. We succeeded with 10,000. We are done. We didn't succeed, obviously, with 1,000 because we tried that first. Okay. So how would, how would the trace look here? So this is even, even if I don't know how really RSA, even if I didn't implement it, what I would look in the RSA trace is essentially these two huge patterns. Because almost everywhere, there is implemented RSA CRT. That's standard because it's roughly speaking three times faster or around that. So almost, it is almost always two huge patterns. So this will be the exponentiation number one. This is exponentiation number two. In RSA, in OpenSSL, they first used DQ, then the second DP. What's happening before? We can just be guessing, but maybe the modular inverse is happening. Also, somewhere we should expect the precomputations. So probably just before the real exponentiation happens, there is, there are some precomputations performed and what we should expect at the end is somewhere here, probably there, maybe this spike, somewhere around these spikes, there should be this combining of two messages, of two parts. So there is one exponentiation, second, and then there is, that has to be combined. That's what Pravin shown. Okay. Yeah. So actually, this trace is quite readable. Okay. So actually, everything is explained here. So again, recombination is here. We didn't mark it, but it's there. This is already slightly pre-processed trace. Essentially, it's just low-past slightly. So again, blinding, it's actually my best guess that this is the inverse. That's what costs time. Absolutely slow pass. Okay. So here, we can find this nice pattern. So the first step, it's not visible here because we are only showing one trace, but this is quite a lot of time. Okay. We don't give you the time, but we are talking about the whole operation is probably like 500 milliseconds or something like that. 650. Okay. 650. So how to, what will happen there is supposedly everything is constant time, but not everything is really constant time. So there will be quite a bit of misalignment. The other thing will be the trigger. It's not very, it's never really perfect. So first, to start any analysis, we should somehow have these traces at the, like each value should be processed exactly at the same time in our traces. So what we need to do, we need to start somehow the alignment. So we first, we zoom in somewhere here, let's say, and we find this distinctive pattern here. So we have the, we have the, in our software tool, there is a mechanism to essentially align on patterns. It uses some, it uses correlation essentially, but roughly speaking, if we, if this tool sees two similar patterns somewhere, it will just correct the offset, the time offset. Okay. This, this is maybe not the most exciting part of work, but that usually takes quite a few trial and errors tries. And what we did is essentially we tried manually as many times as we could to, and visually check the traces. Do they seem aligned? And from these 10,000 traces, after, after enough work, we got 8,000 traces that seemed to be aligned. What happened also here? Yeah, now I, now I see, I remember. So we got these 8,000 quite well aligned traces, but what we started noticing is that the trace seemed to be slightly vertically moving. That's usually, that's, that sometimes happens due to the, let us imagine that we run this acquisition, it takes, we run it for the night, the temperature changes. And then what happens is that the trace starts moving slowly, like for example at 8 o'clock in the evening, it's, it's maybe somewhere high because it was maybe summer, warm outside, and then it goes slightly lower. This is, this is just a, this problem of course can be solved in some kind of controlled environment or really stable temperature. But well, we, we applied one of our modules that, one of our software tools, let's say that, that tries to compute the mean, compute the variance, and correct everything. It's not the best, but again, it worked. So we were happy. Okay. Another thing, maybe just to give a bit of feeling, this alignment on 10,000 traces already takes probably an hour or two, a single try. But what about the cross-correlation? Cross-correlation requires, it's a squared algorithm. So we've seen there were these, on the simulations, everything were squares. Okay. So we cannot really run it on 80 million samples. That would take way, way too much time. So first thing is using Windows re-sampling. So essentially that's a compression method that we take like 100 samples and add them together and get one. It also, there is a hope that it reduces signal to noise ratio. So let us see how, how the window re-sample output would look like. I'm not sure how visibility is, but essentially there, there started occurring such patterns. Essentially there is that it's a bit similar to low pass. So what we started seeing here, so this is just the beginning of the trace. So we are looking here now, a bit more carefully. So what, what we notice is that there are essentially, there, I think, 15 patterns here. And then they are starting being a single four groups of, of, of, of distinctive patterns. So there are five, there are five peaks in this pattern. So we can guess, since there are five, since there are five peaks, there should be four squares and one multiply. So that will be processing four bits. And this thing is just pre-computation of points. How the pre-computation of points is done is essentially, first we start with m, we multiply m by m, we get m squared, then we multiply m squared by m, we have m to the third, and we go on like that. So that matches what we see in the code. So what we did later, what happened is that these patterns here are not perfectly aligned when we take the traces, when, when we put traces on top of each other. So we used another module that essentially aligns at this window. So the traces are, are aligned on top of, of, of each other. Again, this is again one of our tools that we have there. There are other things that we, okay, let's go just further. So now we have the aligned traces. This is, this is again the pre-processing. And this is our, this is already the, the, the exponentiation part. If everything is aligned correctly, we could already try to play with cross-correlation. And actually that's how we did it the first time. But let's, we, we slightly improved the processing. So what did we do? We realized that what we really, what we are really interested is the, is the multiplication. So we brought our own module that essentially cuts off everything that looks like multiplication and everything that looks different. Essentially we kicked it out. So then we will only do cross-correlation on the, on the multiplications. So that was our, our result. So essentially we have these, these guys that we hope the leakage will be only here. So what can we do here? Okay. So this is, these, these, these multiplications are coming only from exponentiation. So what do we hope for? We hope that we would be able to detect cross-correlation between groups of bits that are the same. So for example, if I have 0, 0, 0, 1, 1 multiplication and then somewhere later 0, 0, 0, 0, 1 again, I would like to see cross-correlation there. The same if I have 0, 0, 1, 0. I should see all the, that cross-correlating with all the other places where the value corresponding to 0, 0, 1, 0 is being processed. And that, that value will be square, essentially m squared because this is 0, 0, 1, 0. So it's 2. So m squared. Okay. So we run it. What did we see? The picture is maybe not, not completely clear. What? Yeah, yeah, yeah. But okay. I will go slowly because that's actually how we got here. So on the next picture that we saw, everything will be clear. But here essentially this is cross-correlation within a single multiplication that always happens. Maybe it's not very visible but we saw, we started seeing such peaks here. At the beginning I thought that my eyes are getting crazy but then, then, then we started thinking maybe this is a real leakage. So we checked just manually what is the secret key here and what is the secret key in the subsequent operation here and then we discovered the same. So these four bits were the same. So then we knew, okay, we have the leakage. So later for the same traces we essentially used, we had the same picture but we used GIMP with binary threshold and that's just easier to detect the same, the, the, the same very weak cross-correlations. But what we discovered, it actually worked. So this was, these two operations share the same, the same, the same value. Okay. So when we would work and when it would not work. So that value intuitively should always work because that's how we just described the algorithm. But that's not true because open SSL treats zero, treats one differently. It doesn't perform multiplication by one but that's something strange. So for once we never see cross-correlation like that, we never see these spots. What do we see then? We see very, very strange pattern here. So we actually don't, we cannot recognize multiplication by one, by the, by the cross-correlation. We can only recognize it by the internal cross-correlation here. The pattern is completely different and actually we didn't analyze why it's like that. We are just happy that we can recognize it. Okay. Okay. We are getting close to the end. What we couldn't recognize here is we know that these two operands share the same key and then we maybe know that these two share the same four bits but we don't know what is that value. So what did we do later? That's just exponentiation. And then we went for the pre-computation. So essentially this part here corresponds to these 15 pre-computations and this part here corresponds to the exponentiation. Then here we know the order. So we know that the first operation will be computing m squared. The second operation will be computing m to the third, m to the fourth and so on. So if we, for example, would see here cross-correlation and we know that this is the tenth operation, then we know that here that point is being processed. So essentially when we compute, for example, m to the power of three, it's essentially m multiplied by m squared. So we search for the cross-correlation between m squared and the actual value somewhere here. So for example, let's say this one. As far as I can say based on this picture, this is m to the power of three. So if I go here, then I know that in this operation there will be, since this is the third one, then it was m squared multiplied by m. So these, the bits here should be 0, 0, 1, 0. That's all. So what is strange on this picture? The strange thing on this picture is this thing. So what, what that would really mean? And that, that actually is multiplication by, in this case, by 0, 0, 0, 1. Here the problem is that there is m multiplied by m. So that means that here there is multiplication by m. That cross-correlates with everything. Because for each of this part of the loop, there is, I multiply m by m, then m squared by m. Then, so the operation that multiplies by m to the power of one, cross-correlates with everything. Still good enough, because we can, we know exactly the value. Again, what will not work here? It's, it's, it's m to the power of 15. m to the power of 15 is never used, because there is no m to the power of 16 computed here. So that will have to be brute-forced. But that's the only thing that will have to be brute-forced. So essentially, m to the power of 16 will not cross-correlate with anything. So, yeah, actually, yeah. Okay. Okay, these are, these are just a few, a few examples, but it's exactly, it's exactly how I described. So here is 3, here is 12, so we can recognize the values here. So conclusion. First of all, straightforward binary exponentiation are insecure against, against, against SPA. Multiply always implementation KB can be also attacked with cross-correlation. Message blinding plus multiply always isn't, is not good enough to stop, to stop the attack. So now there is exponent blinding mentioned here. We didn't explain it, but there, of course, there are more countermeasures. The more countermeasures you add, the smaller chance for the attack, there is for the attack. Again, it's costly. So it's, for example, not in OpenSSL, but in maybe more secure implementations it can be there. Would cross-correlation work in this case? No, it would not work. But I would, I would say that way. There are attacks also for this, in these cases. So you can, it's always possible to pile more countermeasures on top of each other. But, but there are always attacks also that, that are there for, for that cases. If you, well, if you like the presentation, and if you would like to see maybe more or even how we do, try to template attacks or clustering attacks, we have some traces and we will have it in our tent. So then we can maybe even show the acquisition demo or we are initially thinking about trying to do it now, but I think it's, it would be too much hassle. So, well, if you're interested, just come to our tent and then, then, then we can talk more. So public eCrypto is, well, I really like that. So I can talk about that a lot if you are interested. Yeah. Okay. Thank you for the talk. We still have a little bit of time for Q&A. If you have questions, please line up at the mic in the middle. We really would ask you to ask questions and not comments. And yeah, please get closer to the mic. It should be, what tent will you be at for the demo? This is risker tent. It's in the hopper, hopper field. It's in the hopper field. Yes. Close to the Spanish village, I believe. We just came. So, yeah. All right. Hopper field. Thank you. So just to maybe give a bit of a feeling. So from the acquisition to the actual attack, the time of processing the traces, it's like 10 hours or more. But so probably either we will show just acquisition and then already slightly preprocessed traces. So just the full attack is way too much time. Hello. Thank you for the talk. You mentioned that you used a Pico scope for doing the acquisition. Yeah. How did you, what did you use for automating the telling it to start capturing? For what? What do you, how did you mention that there was a trigger going from the PC to the Pico scope telling it to ready itself. What did you use for automating that? Yeah. So we actually, so the trigger was from the device itself coming. Okay. So it's just, you just set it up. Yeah. Yeah. Normally and then just use a trigger. Yeah. So essentially the software was telling continuously the Pico scope arm, arm, arm, arm. And then the trigger was generated by the device itself. But it's simplicity. It's not very hard to make a trigger from the, even from the communication. It would imply that we would have to get more samples slightly. But the misalignment is usually, since this operation is so huge, even if misalignment is in two milliseconds or five, we can live with it. Yeah. Okay. Cool. So, so the, the arm, the repeated arm signal was that being just set from a Pico text standard software? No, we used, we used our own implementation. So, so we have, we have this inspector tool, but just to explain, there are, I, I, I'm aware of the open source implementation online. Oh, I, I wasn't. So, okay. Okay. There are there. I, I'm not sure if I can remember from memory, but yeah, there are. I'll Google. Yeah. So you mentioned needing a whole lot of traces, about 10,000. Yes. What you do is for a real world attack where you're not able to get a device to calculate the same thing that many times over and over. But it's not the same thing. It can calculate whatever message it wants. Okay. So if you've got a real device, it might still implement some kind of like limit on. Yes. It does happen. Sure. So how, what do we do then? So then, then the, then essentially we need to get as clear signal as possible. So this attack, we did on another, on another device, on another also arm cortex, but we used EM. So this is slightly more expensive technique. So we used the electromagnetic probe for that. And then we were able to detect a decent, a decent cross correlation with hundred traces. Okay. However, we are, we are not showing these results, but because it was in a project, but yeah. Yeah. We, we've hundred traces it's possible to do this attack. So this particular attack doesn't require a lot of traces. There are other side channel attacks that do require a lot of traces. Okay. On the other hand, if the target is very protected, we will just, if, or very noisy, well, it's okay to fail then. Any further questions? Then please thank all speakers again. And yeah.