Bonjour, my name is Elie. I work at Google, where I lead the security and anti-abuse research team.
Today, with Jean-Michel, who is here in spirit, we are 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 research 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 the specific hardware and how that can be exploited by attackers.
Here is a concrete example to show you how powerful side-channel attacks are.
Back in 2017, researchers were able to recover Bitcoin private keys out of a Trezor hardware wallet by using side-channel attacks.
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 that you can exploit through side-channel attacks.
And from the defender side, side-channel attacks are very difficult because they are very hard to debug and fix.
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 attacks are both very important and hard to debug, it means that there is 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 vulnerable to side-channel attacks.
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 attacks.
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 combine the two 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, 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 debugging tool, which we call SCALD, which stands for side-channel attack leak detector, and how that works in practice.
And to make it very concrete, today I'm going to show you how we can use SCALD to debug TinyAS, a very vanilla plain implementation of AES, 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 us today.
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 explainability, and how you go about explaining what a machine learning sees, or understands, 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 it all together to, well, pinpoint the leakage, and I'll show you how it works in practice for the target, our tiny ass on SMT32.
We can follow along by getting the slide, at the very least, and hopefully link the code by going to elit.net slash code.
As I mentioned, the purpose of this talk is to be very practical, down-to-earth 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, the 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.
With that out of the way, let's start with recapping what side-chain attacks are.
At its core, a side-chain attack is an indirect measurement of a computation result using an auctioneering 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 auctioneering mechanism.
Side-chain attacks are used in many, many ways to attack various targets.
Obviously, as discussed in this talk, they are used to recover encryption keys out of hardware secure implementation.
They are also used in web security to perform blind SQL injection, where you cannot see the return of a SQL statement on SQL injection.
And then, they are also used to steal passwords and PINs from secure implementation.
And they are also used, as I mentioned in the early example at the beginning, to recover crypto-wallet private keys.
Those are only four examples of the many ways you can use side-chain attacks, which is basically when you need to verify something you cannot observe, a side-chain attack is usually the way to go.
Let's make that a little bit more concrete for our use case.
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.
While it's 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 uses 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 vary 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 a 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 parts of the CPU will be used, and as a result, some parts will be hotter than others.
A little bit arcane, not most rarely used, I think.
I haven't seen very much concrete examples, but it does exist.
Last but not least, we also have what we call electromagnetic 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 side-channel attack, timing being also important, as I've mentioned.
But really, current and EM is probably like the two leading technologies these 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, well, about 10 times the same pattern, and they do correspond to the 10 rounds of AES.
So you can visually see on a non-protected, or very likely protected AES, that we can observe the round by just looking at the power trace.
If we can observe it as human, it means there are some statistical information there that can be exploited to understand what is happening.
And that's, in a sense, the side channel, the side effect, that we can use to recover an AES key.
In a nutshell, how you go about that?
Well, you get a CPU, that's 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 side channel 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.
It doesn't mean that's the best, it's just what works for us.
We use an UAE CheapWaveScope Pro.
And for some of our work, however non-distop, we also use a PicoScope 6000, when we need faster sampling, when the target is very fast, and we need a lot of information.
So, for example, last year, when we talked about SCAML, which is a way to do a side-channel 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 CheapWave scores.
And again, this is not an app, this just happens 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 side-channel attack are, let's talk about how you would go about using AI to perform such an attack.
Well, this is something we call a side-channel attack automated with machine learning, also known as CAML.
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 the model that we create using a CAML attack to do the explainability and then find out what the leakage 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 eddy.net slash CAML.
I also probably put a link on to Twitter if you want to follow along.
And again, you'll have way more detail.
I'm going to try to shrink down the explanation as much as I can so you can follow along.
But if you want all the detail, they are in 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 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 collecting 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 very high sampling rate.
In this specific case, this year we are changing the model because this time this code 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 AES starts and what time it ends.
So you can also create shorter traces.
The reason why to do shorter captures is because machine learning has an easier time if you don't capture the whole thing, because that means it spends less time when it trains 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.
The way sectional attack assisted by machine learning works is very similar to the traditional sectional 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 use two of them to normalize them between 1 and minus 1 because machine learning actually works in that range, which is not what your traditional oscilloscope would output.
And then we feed those traces to a deep neural network and we train to make predictions on what he thinks are the values which can be used to recover the key.
And then we combine those to do a statistical estimate and hopefully you get back your IS key.
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 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 in a sense than the traditional template attack because of the reason mentioned.
When you do a sectional attack, you do not necessarily directly target to recover the key.
You target what we call attack point. In the case of TinyAIS, there are two points which works really well, which is a sub-byte in, which is when you XOR the key with a plain text.
And there is also the sub-byte out, which is when you look at the output of the else 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 based on our experience and this is something which is a point.
So basically, the machine learning will now predict the key. That really doesn't work when you try that.
But instead, it's 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 will predict the sub-byte in, what it does is you get a trace and then it tells you, okay, here is a softmax.
So a most probabilistic output of 256 values will tell you which is the most important value, but also what you think is the second-best value, third-best value, and so forth.
And that's what the softmax does.
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 log10 because of finding errors.
And then you combine them and hopefully by combining them, you get the most likely value and 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, well, you need as little as that too.
So basically three, four traces for simple cases, you get the correct value and you recover one byte of the key.
What's important to mention as well here is we have one model per byte.
So we have 16 bytes, which is the 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, well, 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.
However, there are some difference of accuracy between the bytes, but that's not relevant for this talk.
Okay.
For those fractures, this year we use a hyper-tuned residual 1D convolutional 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, 300,000 neurons per meter.
It's way tuned and it works really well out of the box.
This is kind of like our go-to model these days, 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 models 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 hopeful, knocking on wood, 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.
For Scaled, 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 something that is a validation accuracy, to be clear.
So on data, which has not been seen during the training, you reach something between 63 for the worst one, which I think is byte 4, up to 87% for the best one, which is byte 0.
And again, they're all between that.
For Scaled, 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 the model 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 overkill.
And as I said, unsurprisingly, because 10 years is not protected against side-channel attacks and our model is really well-optimized, we have high accuracy in 5 epochs 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, OK, how does it help us to go back and, well, find where the leak is coming from?
Well, this is where you need to add another piece, which is deep learning explainability.
So what is deep learning explainability?
Deep learning 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 you can ask the question, OK, 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 colors of the tail of the cat or maybe the dog has 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?
And that's what explainability is about.
It's 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 does the 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 Skoal to have models which work well.
Not necessarily 99%, but at least very well because we need to have examples of predictions 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.
On the other side, you give back the picture we had.
And we say, OK, why did you believe it was a boxer?
And hopefully, it will tell you, well, I look at the face of the puppy and it's a boxer.
OK, that's reasonable.
And you can ask also, OK, how about the cat?
And hopefully, and again, this is a real example out of one of the explanation techniques,
it 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 a cat,
but the most important thing is there are stripes.
As you can see, it's the right part of the image.
And you're like, OK, that makes sense.
I guess a cat which has stripes is probably a tiger cat.
Makes sense.
The machine learning is actually looking at what it should.
Was this 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 Pascal Vocabulary, Visual Vocabulary.
And what happened was, in the early version of this data set,
I think one picture in five horses had a bottom left name of who took it.
And what the machine learning learned was not to recognize the horse,
it was to recognize, well, that there was something on the bottom left.
All right, so that's what explainability is for, so that's what we would like,
because essentially what we want to ask the machine learning is,
given an input and a prediction,
can you tell me how you figure out what is leaking, right?
Where do you get information to get to the conclusion that it's the correct key,
or the correct attack point?
Well, that seems great in practice.
It seems great in theory, and we can see where it's going.
The thing is, that doesn't tell us how we're going to combine this explainability techniques
and dynamic analysis to debug leakage, right?
Because so far, all I explained to you is maybe how we can get some part of the output highlighted,
but doesn't tell you how you go back to know where the leakage comes from.
And so that's all the difficulty of code,
and that's why it took us about one year, over a year,
to actually really know how to get that done.
It's because you need to be very creative around how to combine those things,
which in theory should make sense, to actually get the result you want.
So let's deep dive 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, okay, 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 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, the specific type, the SMT, F4, 32F4, and the firmware.
So in our case, the firmware we choose is NES,
and we're going to emulate it to be able to know
at which every instruction cycle in the ARM CPU corresponds to which opcode.
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.
And so with that, we can combine both of them.
We can combine the leakage map, which tells us,
at what time each instruction was run, to be able to annotate the code,
which were the leakages, that's the idea.
In practice, this is where it becomes complicated.
There is, of course, a lot of techniques.
Here is a screenshot, here is a figure from one of the recent paper,
which is called Static Check for Static Map,
which basically we're looking at how efficient is different type of explainability technique.
You can see some of them have more defined opcodes than others.
In this specific, in our research, we tried a bunch of them,
including a guided graph cam, which seemed, when we started,
to be giving the most defined and precise leakage.
And then we tested a bunch of them.
The idea was, which explainability technique would work best for us,
because we wanted to highlight very precisely 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 mask.
And then you eliminate all the noise,
and hopefully you get the bottom image, which is this leakage map.
You can see it's strided 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 for byte 0,
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 tight channel attacks to detect whether or not there is a leak.
So it's a very robust way, statistical, well-proved way, kind of like our baseline.
So the signal-to-noise ratio tells 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 GRADCAM++, which is one of the latest techniques,
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 defined.
There are zigzags in place, but not exactly the same.
And then the activation map looks almost equivalent to the GRADCAM.
Even the activation map looks 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, right?
So what we can do is we can take our test traces that we know the machine learning is successful at predicting,
and then we can decide to use the leak map and, let's say, remove the four points, or the eight points,
which are supposed to be the most important, according to the leakage map, out of the trace.
We can just literally blank them. Blanking them means put them to zero, or to minus one.
Put them to zero, but some idea.
You basically remove the information there, and hopefully, if they are the most important part of the prediction,
then the accuracy of the model, if you feed it again, should result in aggregate to decrease accuracy, right?
The idea is that if you blank out the points, which are used by the machine learning 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 four points.
Why four points? It's because an instruction text, when we capture them with the oscilloscope, is four points, right?
So each cycle of the CPU is supposed to be four points.
So if we know that, we say, okay, let's try to remove the most important cycle.
If we do it with SNR, the technique seems to work, right? 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, was like, oh, well, it doesn't work that well.
SNR is better. So activation map doesn't work really well.
And then, if you remember, I showed you that the leakage map are almost the same, and the result are the same for GraphQAM+.
So the idea seems to work in the sense that SNR works.
Our deep learning explainability, 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? Let's go back to that.
And so the way we went about that is like, OK, 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, OK, let's invent a new technique for a specific task.
But the thing is, we are trying to do something very, very unique, very, very precise.
We don't want to have like the exact region and have 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 underlying algorithm you want to use is a little bit different,
we can use occlusion. We should literally try to use a window to do that.
And so Scaled Explanation Technique is actually exactly that.
It's a hybrid version of occlusion where we start to eliminate large regions
so we don't choose more regions, 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, if we took byte 0 and byte 7,
it is clear that byte 0 is before byte 7 for in-terms of leakage,
which makes a ton of sense because obviously TinyES processes one after the other.
It's not vectorized code. So that will be exactly what we expect.
Okay, so we're like, okay, trace-study code should work, right?
So go back to the benchmark, run the thing, and voila!
The numbers are way better, or at least better, for byte 7.
And so, again, so now we have a technique which works better.
Our map is more precise, so we hope that the leakage pinpoint 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 and SCALD basically find roughly the same region,
except the region is better defined with SCALD, 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 state-of-the-art
and also finding something completely out of the Teracle model.
So if the Teracle model is more precise, it's good.
And so, as I said, benchmark shows that in every case,
SCALD actually outperformed 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.
It takes, I don't know, about 10 minutes to explain a network.
Okay, now let's explain in greater detail 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 on the CPU.
And we basically have a state automaton to try to emulate what's happening during the leakage map.
But the idea is you want to do AS start, run the AS, AS stop,
and basically pick up what is in sync with the leakage map.
And then what happens then is you get mapped ASM.
So what you get is you get, okay, this cycle maps to this time,
this point in the track map to that cycle, 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, the firmware we have is in debug mode.
Again, we're back to this idea that this is a tool for developers.
So when you test for leakage, you can compile with the debug symbol because you don't try to harden it.
We just want to debug it.
So we have the debug symbol which helps us 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 there's a theory, but we haven't told you or haven't shown you if it really works in practice.
And the thing is, before I do that, I want to be on phase three of this project.
The first one is, we spend a lot of time talking about explainability because if we don't have extremely precise explainability technique,
which exactly pinpoint what point in the trace is responsible for the leakage, we're going to fail.
We're going to fail because most instructions on ARM are two, maybe three, maybe four seconds long at most.
Not at most, but one to two instructions for an additional standard.
So it's literally four to eight points.
Like our margin of error is maybe one 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 a Windows of 10 points,
it's meaningless for us because then it might be three instructions.
And those instructions might belong to a 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, let's say, pipeline flush,
if you don't take into account the CPU pipeline size and things like that, you get it wrong.
You get it wrong because you're going to shift everything by, let's say,
by one cycle for each addition, then your whole traces 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... we use, I think, a one million data point,
something like that. And then even for the explanation time, we use 60,000 traces.
You need 16 models. As I mentioned, you can shorten the time, of course,
by using good models who convert 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, most of it is parallelizable because the 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.
All right. So at this point, you're like, OK, he gave me a long speech of why it's really hard.
So probably they failed. And it's really, really hard because, yeah, emulating a CPU is hard.
And I'm telling you it's true. I don't think we have perfect emulation of CPU.
I think we have very precise emulation of the instruction we need for AES.
In particular, one thing we don't have, and disclaimer, is we don't have implemented mapping for divide.
Why? It's because division actually takes a lot of cycle and a very different branch of cycle on ARM CPU.
So we don't really know what to do there. So that's only working for now for AES and for 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... if the model is targeting sub-byte in,
then it must exploit something in the add-on key because add-on key is where you do...
the key exploits the plaintext. So it must have most of the... mainly cache should be there.
So it's a theoretical thing. And so what we do to verify that what we said works is to actually try to verify that.
And so that's what the schedule output looks like. It's a terminal thing.
You basically run it and at the end spit out this, as I said, tree, which maps cycle instruction,
which is not displayed for visibility, to code line, which is basically numbers.
And then I filter everything which is not leaking. And then what this mapping tells you is, yes,
the main leakage is on line 2.13 of add-on key. So that's promising.
It also has, interestingly enough, a second leakage, which is later on into the cipher functions.
So what is the line 2.13, 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 XORed with the plaintext.
So the model, and Scaled in general, really clearly is using what a theorem would predict,
which is there is a leak in that specific line because they are doing...
they are showing the value of the register with some assignment.
And so this is what it is. So that's a success.
That's what gives us confidence that what we do works in practice. It's really giving us interesting results.
I will not claim it works in every case. I'm sure that with more complex implementation,
like masked AES or more complicated security, the result might be drastically different.
As I said, our emulator did not fully emulate all the operations it 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 tools
who go back from leakage to exact line of code.
As far as we can tell, it's the first time it has ever 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 went when some of the registers are unloaded.
And so this is where it started with a mixed column, if you look at line 371.
So maybe that's what happened, it's unloading some of the registers and then going back.
We need a little bit more analysis for that, but basically it will be interesting to know why there is another leakage.
So hopefully today I showed you how we use Scalar to automatically isolate the number of codes
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 and we get feedback 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 a faster iteration
so we all benefit from stronger, more secure devices.
And to take over the talk, as I said, as we discussed last year, machine learning is a way to automate
such an attack and you reach state-of-the-art with it so it's really one of the most...
it's at the forefront of such an attack and this year we flipped the use case on its head
which is really what was the intent of the project from the onset two years ago
which is to try to use all those knowledge to actually help developers building better tooling
for them to reduce the cost of developing secure implementation and make them better.
So that being 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 into crypto, into 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 DEF CON as you probably do. I hope you're all well
and if you would like to follow up and keep up with what we're doing, we try to publish as fast as we can
modulo some delay to provide you information about what we do on such an attack on the website.
Hopefully we'll 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. Thank you so much. Bye.