start	end	text
5410	12010	Bonjour, my name is Elie. I work at Google, where I lead the security and anti-abuse research team.
12010	20070	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.
20170	34390	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.
34390	44850	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,
44850	51250	instead, it targets the implementation and the interplay with the given hardware.
51410	62830	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.
62830	66570	Here is a concrete example to show you how powerful side-channel attacks are.
66570	76030	Back in 2017, researchers were able to recover Bitcoin private keys out of a Trezor hardware wallet by using side-channel attacks.
76270	89290	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.
90590	96690	And from the defender side, side-channel attacks are very difficult because they are very hard to debug and fix.
96690	103850	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.
103930	113450	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.
113450	115770	And that's where these projects come in.
115770	123750	And our idea was maybe we can try to develop new technology to accurately pinpoint the code which is vulnerable to side-channel attacks.
123750	133930	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.
134350	136090	So that was the idea we had.
136090	152950	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.
153190	162710	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.
162710	168870	Well, actually, no. This talk, as I promised, is a hacker journey, so we want to make it very concrete.
168930	180250	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.
180250	197190	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.
197190	220190	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.
220190	235330	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.
235330	246330	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.
246330	262330	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.
262330	269070	We can follow along by getting the slide, at the very least, and hopefully link the code by going to elit.net slash code.
269650	287610	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.
287610	299530	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.
299530	308690	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.
308690	314350	With that out of the way, let's start with recapping what side-chain attacks are.
314350	322330	At its core, a side-chain attack is an indirect measurement of a computation result using an auctioneering mechanism.
322330	331960	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.
331960	338220	Side-chain attacks are used in many, many ways to attack various targets.
338260	344780	Obviously, as discussed in this talk, they are used to recover encryption keys out of hardware secure implementation.
345180	353000	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.
353000	358920	And then, they are also used to steal passwords and PINs from secure implementation.
359200	367080	And they are also used, as I mentioned in the early example at the beginning, to recover crypto-wallet private keys.
367080	377920	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.
377920	380020	Let's make that a little bit more concrete for our use case.
380020	391580	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.
391780	394780	And while it's running, we have some leakage.
394840	397420	The first one is how long the computation takes.
397420	405900	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.
405900	414320	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.
414320	418820	That's one of the examples, but again, timing is how long the computation takes.
418860	421740	Then we have the one we use in this talk, which is current.
421740	433440	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.
433440	438060	And so that's what we can measure, and that's what we can use to infer what is happening.
438480	442800	Then we have a third one, which is less used, but it's still possible.
442800	443840	It is heat.
443840	452740	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.
453260	457500	A little bit arcane, not most rarely used, I think.
457500	461200	I haven't seen very much concrete examples, but it does exist.
461200	466860	Last but not least, we also have what we call electromagnetic emission, EM.
466860	473100	And EM is also a very powerful channel, widely used to recover public keys.
473100	481680	It is, with current, probably one of the two most used in side-channel attack, timing being also important, as I've mentioned.
481800	486280	But really, current and EM is probably like the two leading technologies these days.
486920	488540	What does it look like in practice?
488540	492720	So here is a power trace of an AES.
492720	504160	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.
504300	513420	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.
513420	522040	If we can observe it as human, it means there are some statistical information there that can be exploited to understand what is happening.
522040	529600	And that's, in a sense, the side channel, the side effect, that we can use to recover an AES key.
529960	531480	In a nutshell, how you go about that?
531480	536700	Well, you get a CPU, that's the target, to do the encryption.
536700	543440	And what you do is, you do record while the encryption is performed, the power trace using an oscilloscope.
543660	554740	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.
554740	558300	And the statistical estimate will help you to recover your AES key.
558300	560220	This is how it works.
560680	565160	If you wonder what type of hardware we use, and again, this is what we use.
565160	567660	It doesn't mean that's the best, it's just what works for us.
567700	570500	We use an UAE CheapWaveScope Pro.
570820	580380	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.
580380	592420	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.
592420	595900	For this work, we just use plain old CheapWave scores.
596120	604460	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.
604880	613620	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.
613660	620280	Well, this is something we call a side-channel attack automated with machine learning, also known as CAML.
620280	624200	This is what we did present in-depth last year.
624200	636240	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.
637120	643200	If you want to have more detail, by the way, about this type of attack, well, you can check out last year's talk.
643200	649320	It's available on my website at eddy.net slash CAML.
649320	653260	I also probably put a link on to Twitter if you want to follow along.
653260	655220	And again, you'll have way more detail.
655400	660440	I'm going to try to shrink down the explanation as much as I can so you can follow along.
660440	663660	But if you want all the detail, they are in the previous talk.
663920	671400	I also want to say this year is different from last year, so for people who follow both, in two senses.
671400	685760	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.
685940	696360	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.
696960	708480	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.
708480	717000	In this specific case, this year we are changing the model because this time this code is for people who are developing implementation.
717100	723160	So we do assume you have the code, you have the hardware target, you can put it in debug mode.
723160	727260	And so we don't need to create asynchronous traces.
727260	734200	We also have a good idea, if you're a developer, at what time AES starts and what time it ends.
734200	737060	So you can also create shorter traces.
737420	750460	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.
750460	755440	So again, this is a white box attacker model. It makes more sense for that work.
755440	765240	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.
765240	772600	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.
772600	781520	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.
781860	788680	The way sectional attack assisted by machine learning works is very similar to the traditional sectional attacks.
788680	795340	As in the previous case, you have the encryption which is running, and then you capture the trace.
795340	806820	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.
806820	819360	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.
819360	826540	And then we combine those to do a statistical estimate and hopefully you get back your IS key.
826920	833800	One of the advantages of that, as illustrated last year, is that you do not need to do any kind of pre-processing.
833800	841280	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.
841280	852120	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.
852120	858280	When you do a sectional attack, you do not necessarily directly target to recover the key.
858280	870160	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.
870160	875540	And there is also the sub-byte out, which is when you look at the output of the else box.
876540	884640	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.
884640	890560	So basically, the machine learning will now predict the key. That really doesn't work when you try that.
890560	903640	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.
904020	906660	So the target point today is sub-byte in.
907500	914260	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.
914260	924660	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.
924740	926760	And that's what the softmax does.
926840	936740	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.
936740	946280	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.
946280	947840	So it will quickly converge.
947840	953340	Last year, we showed that for 10 years on a full trace, we only need four traces.
953340	960800	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.
960800	968120	So basically three, four traces for simple cases, you get the correct value and you recover one byte of the key.
968760	972720	What's important to mention as well here is we have one model per byte.
972720	975580	So we have 16 bytes, which is the normal input.
975580	979620	We have in reality 16 models which are performing one byte at a time.
979620	982200	It is easier for the machine learning to predict one byte at a time.
982200	984620	So, well, you have to train 16 times.
984980	988660	I'm not going to show that on the slide because it's not relevant.
988660	990900	If you can wait for one, you can wait for 16.
990940	996280	However, there are some difference of accuracy between the bytes, but that's not relevant for this talk.
996520	997200	Okay.
997760	1008060	For those fractures, this year we use a hyper-tuned residual 1D convolutional neural network.
1008140	1010280	It's different between this model and last year.
1010280	1012800	This model is way more efficient.
1012800	1018620	It's smaller and I think it's 300,000 points or something, 300,000 neurons per meter.
1019340	1022300	It's way tuned and it works really well out of the box.
1022300	1028640	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.
1029320	1037140	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.
1037140	1039400	I said last year it will be soon.
1039400	1044680	We have some technical difficulty to make everything reproducible and we have a lot of improvement.
1044680	1058060	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.
1058060	1067840	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.
1067840	1073200	So you train 16 models. As I mentioned, the accuracy varies.
1073320	1076860	As you can see, you reach something that is a validation accuracy, to be clear.
1077200	1089800	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.
1090040	1092080	And again, they're all between that.
1092780	1094860	For Scaled, it doesn't really matter.
1094860	1103040	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.
1103220	1107880	We want to know what the model is using when it's correct.
1108020	1114600	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.
1114680	1118080	So you do 3 per hour and you have 16 to go.
1118080	1122260	So, you know, that's already about 5 hours of training time.
1122260	1126280	So we don't want to do 20 epochs, which would be completely overkill.
1126600	1139260	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.
1139580	1143200	Now, the model is good at extracting the key.
1143200	1147220	So we are able to use it and we can consistently recover keys.
1147220	1153480	Now the question is, OK, how does it help us to go back and, well, find where the leak is coming from?
1153480	1158380	Well, this is where you need to add another piece, which is deep learning explainability.
1158680	1160680	So what is deep learning explainability?
1160920	1165460	Deep learning explainability was first developed, I believe, for vision.
1165460	1168440	And the idea was, I have a deep learning network.
1168480	1173480	And it says, in this picture, we have a boxer and we have a tiger cat.
1173580	1176320	Now you can ask the question, OK, but why?
1176320	1179560	Does it really look at the cat? Does it really look at the dog?
1179560	1182360	Or does it look at statistics? I don't know.
1182360	1191060	Maybe the stripe colors of the tail of the cat or maybe the dog has a leash or something like that.
1191060	1195640	So what you want to do is you want to have a way to ask the neural network, what do you look at?
1195640	1198120	And that's what explainability is about.
1198120	1202980	It's being able to say, for a model, how does it come up with a given prediction?
1202980	1206740	Why for this specific class, I'll put one output neuron.
1207060	1210360	What did you use as input and what does the input matter to you?
1210520	1214260	So it's basically almost inverting the machine learning model, if you will.
1215040	1217420	And so we call that explainability.
1217500	1220480	There are many techniques, but the idea is you...
1220480	1225380	All the techniques have in common that you feed the machine, the model, to the explainer.
1225680	1228840	Then you feed the input you would like information about.
1228840	1233420	And then you have to tell him which class you want to have an explanation for.
1233420	1239880	This is why, as I explained earlier, we need for Skoal to have models which work well.
1239880	1246100	Not necessarily 99%, but at least very well because we need to have examples of predictions which are successful
1246100	1252060	because we want to know for a given trace and a successful prediction what to think.
1252060	1255440	So, as I mentioned, you give it to the explainer.
1255440	1259960	On the other side, you give back the picture we had.
1259960	1264020	And we say, OK, why did you believe it was a boxer?
1264020	1271440	And hopefully, it will tell you, well, I look at the face of the puppy and it's a boxer.
1271480	1273240	OK, that's reasonable.
1273640	1276820	And you can ask also, OK, how about the cat?
1277600	1282840	And hopefully, and again, this is a real example out of one of the explanation techniques,
1282840	1285020	it will tell you, well, I look at the cat.
1285020	1289800	And the reason why I think it's a cat is because, well, there is a face of a cat,
1289800	1291660	but the most important thing is there are stripes.
1292200	1295040	As you can see, it's the right part of the image.
1295700	1297360	And you're like, OK, that makes sense.
1297380	1301240	I guess a cat which has stripes is probably a tiger cat.
1301240	1301980	Makes sense.
1301980	1305420	The machine learning is actually looking at what it should.
1305680	1307980	Was this technique ever useful?
1307980	1309920	And the answer is yes, absolutely.
1309920	1314820	There is this very, very famous data set in machine learning for vision.
1314820	1319180	And it's called the Pascal Vocabulary, Visual Vocabulary.
1319180	1324140	And what happened was, in the early version of this data set,
1324140	1333400	I think one picture in five horses had a bottom left name of who took it.
1333420	1336940	And what the machine learning learned was not to recognize the horse,
1336940	1341720	it was to recognize, well, that there was something on the bottom left.
1341760	1344880	All right, so that's what explainability is for, so that's what we would like,
1344880	1347960	because essentially what we want to ask the machine learning is,
1347960	1352140	given an input and a prediction,
1352140	1355260	can you tell me how you figure out what is leaking, right?
1355360	1359940	Where do you get information to get to the conclusion that it's the correct key,
1359940	1361520	or the correct attack point?
1362560	1365160	Well, that seems great in practice.
1365160	1367740	It seems great in theory, and we can see where it's going.
1367740	1372020	The thing is, that doesn't tell us how we're going to combine this explainability techniques
1372020	1374460	and dynamic analysis to debug leakage, right?
1374460	1381380	Because so far, all I explained to you is maybe how we can get some part of the output highlighted,
1381380	1384680	but doesn't tell you how you go back to know where the leakage comes from.
1384960	1387680	And so that's all the difficulty of code,
1387680	1391800	and that's why it took us about one year, over a year,
1391800	1394580	to actually really know how to get that done.
1394580	1399220	It's because you need to be very creative around how to combine those things,
1399220	1402760	which in theory should make sense, to actually get the result you want.
1402760	1405400	So let's deep dive into how you get there.
1405600	1407680	Our game plan was fairly straightforward.
1407680	1411700	Again, we start with an explainer, we're going to give it our train models,
1412240	1415160	and then we're going to give it the trace and the prediction,
1415160	1419500	and say, okay, please tell me of the trace,
1419500	1422220	what are the important points for you to make your prediction?
1422220	1423860	We're going to call that the leakage map.
1423860	1431860	Then we're going to also run, not necessarily after, but in parallel,
1432840	1438000	a target emulator, which is basically we're going to run our target,
1438000	1445300	which is the given CPU, the specific type, the SMT, F4, 32F4, and the firmware.
1445300	1448060	So in our case, the firmware we choose is NES,
1448060	1452420	and we're going to emulate it to be able to know
1452420	1460240	at which every instruction cycle in the ARM CPU corresponds to which opcode.
1460240	1464560	So basically we need to know at what time, precise point in time,
1464700	1470360	a given code instruction was run, and then which code instruction was run.
1470360	1474160	And so with that, we can combine both of them.
1474240	1482400	We can combine the leakage map, which tells us,
1482400	1486640	at what time each instruction was run, to be able to annotate the code,
1486640	1489000	which were the leakages, that's the idea.
1490120	1493560	In practice, this is where it becomes complicated.
1493740	1495880	There is, of course, a lot of techniques.
1496180	1500900	Here is a screenshot, here is a figure from one of the recent paper,
1500900	1504020	which is called Static Check for Static Map,
1504020	1508820	which basically we're looking at how efficient is different type of explainability technique.
1508820	1513440	You can see some of them have more defined opcodes than others.
1513800	1517220	In this specific, in our research, we tried a bunch of them,
1517220	1521980	including a guided graph cam, which seemed, when we started,
1521980	1525040	to be giving the most defined and precise leakage.
1525720	1528100	And then we tested a bunch of them.
1528200	1531420	The idea was, which explainability technique would work best for us,
1531420	1537980	because we wanted to highlight very precisely which part of the trace was the most important one.
1537980	1540340	How you do that? Well, you get the explanation,
1540340	1545040	so you run a lot of traces which were successful into the explanation.
1545040	1547120	Here is the activation map technique.
1547120	1554020	Then you combine them, and you normalize between 0 and 1 to create some sort of a mask.
1554020	1557760	And then you eliminate all the noise,
1557760	1564240	and hopefully you get the bottom image, which is this leakage map.
1564240	1568500	You can see it's strided here, and you can see that some places which are lighter
1568500	1572740	are supposed to be the place where the model is leaking the most.
1572740	1577660	So according to activation maps, there is, I think it was for byte 0,
1577660	1583980	very, very early there was a leakage, and very, very late, around the 4000 points,
1583980	1587920	so at the end of our traces, some leakage.
1588380	1591960	Depending on the technique you use, you're going to get different results.
1591960	1595700	The first one we tested is SNR, which is not a deep learning technique,
1595700	1601580	but is the standard technique used in tight channel attacks to detect whether or not there is a leak.
1601660	1607240	So it's a very robust way, statistical, well-proved way, kind of like our baseline.
1607240	1614640	So the signal-to-noise ratio tells you that, as you can see, there is a main leak,
1614640	1617240	and there is a secondary leak somewhere in the middle of the trace.
1617460	1621900	And then if we look at GRADCAM++, which is one of the latest techniques,
1622760	1625140	the results are not so clear.
1625440	1632460	We have a bunch of different points, which doesn't seem to align very well with the SNR,
1632460	1633580	or at least they are less defined.
1633580	1636160	There are zigzags in place, but not exactly the same.
1636520	1642620	And then the activation map looks almost equivalent to the GRADCAM.
1644220	1649740	Even the activation map looks at the output of the layer, the lowest layer.
1650100	1651940	This seems very, very much the same.
1651960	1654320	So how do you benchmark how good these experiments are?
1654320	1657200	So the idea is, well, we have a leak map, right?
1657200	1662620	So what we can do is we can take our test traces that we know the machine learning is successful at predicting,
1662620	1670320	and then we can decide to use the leak map and, let's say, remove the four points, or the eight points,
1670320	1673560	which are supposed to be the most important, according to the leakage map, out of the trace.
1673560	1678300	We can just literally blank them. Blanking them means put them to zero, or to minus one.
1678300	1680600	Put them to zero, but some idea.
1681400	1687120	You basically remove the information there, and hopefully, if they are the most important part of the prediction,
1687120	1694400	then the accuracy of the model, if you feed it again, should result in aggregate to decrease accuracy, right?
1694400	1699700	The idea is that if you blank out the points, which are used by the machine learning to make the prediction,
1699700	1705500	the accuracy should decrease. So mechanically, the best technique should yield the best decrease.
1705780	1711240	Baseline, as I said, 100%, because we only used traces, you remove four points.
1711240	1719080	Why four points? It's because an instruction text, when we capture them with the oscilloscope, is four points, right?
1719080	1722700	So each cycle of the CPU is supposed to be four points.
1722700	1727800	So if we know that, we say, okay, let's try to remove the most important cycle.
1728860	1734800	If we do it with SNR, the technique seems to work, right? It seems we reduced by 57% and 44%.
1735560	1741920	If we do the activation map, and it was our first very big disappointment sometime in the project,
1741920	1747260	last year, not last year, but like a few months back, was like, oh, well, it doesn't work that well.
1747260	1751040	SNR is better. So activation map doesn't work really well.
1751040	1757740	And then, if you remember, I showed you that the leakage map are almost the same, and the result are the same for GraphQAM+.
1759040	1763820	So the idea seems to work in the sense that SNR works.
1764500	1769000	Our deep learning explainability, which is way more complicated and should be way better, doesn't.
1769060	1775240	So that was a little bit disappointing. And so it was like, back to the drawing board.
1775240	1777860	What can we do? Let's go back to that.
1777860	1783140	And so the way we went about that is like, OK, let's write our own technique,
1783140	1790020	because what we want is to only find the top point so we can probably do something with a very old idea,
1790020	1792860	which is occlusion, and try to make it a little bit better.
1793120	1798900	So I know it seems weird to say, OK, let's invent a new technique for a specific task.
1798900	1803140	But the thing is, we are trying to do something very, very unique, very, very precise.
1803140	1806960	We don't want to have like the exact region and have more like a holistic understanding.
1806960	1810140	We want to have like top 5 or top 20 points.
1810140	1813800	So because our optimization for our technique is different,
1813800	1818160	and the type of underlying algorithm you want to use is a little bit different,
1818160	1822620	we can use occlusion. We should literally try to use a window to do that.
1822620	1828360	And so Scaled Explanation Technique is actually exactly that.
1828360	1835100	It's a hybrid version of occlusion where we start to eliminate large regions
1835100	1839380	so we don't choose more regions, and then with convolutions,
1839380	1842140	convolutive occlusion, which is something we developed for this,
1842140	1848920	to actually really pinpoint which part of the trace for the region that we think are predictive,
1848920	1851760	which of the exact points are the most important.
1851980	1858080	And as you can see, the traces are way cleaner than the one we had before.
1858680	1862420	And they clearly outline leakage.
1862420	1865620	Also, as you can see, if we took byte 0 and byte 7,
1865620	1871220	it is clear that byte 0 is before byte 7 for in-terms of leakage,
1871220	1876200	which makes a ton of sense because obviously TinyES processes one after the other.
1876200	1880420	It's not vectorized code. So that will be exactly what we expect.
1881420	1886820	Okay, so we're like, okay, trace-study code should work, right?
1886820	1890620	So go back to the benchmark, run the thing, and voila!
1890620	1895840	The numbers are way better, or at least better, for byte 7.
1895940	1900480	And so, again, so now we have a technique which works better.
1900540	1904280	Our map is more precise, so we hope that the leakage pinpoint will be more precise.
1905220	1909160	And just to give you a visual comparison, to finish on that side,
1909160	1914320	it's very clear that, A, the SNR and SCALD basically find roughly the same region,
1914320	1918320	except the region is better defined with SCALD, which is good,
1918320	1923160	because the SNR is not wrong in general, and B, we have something which is cleaner,
1923160	1927880	which means that we have improved over existing state-of-the-art
1927880	1931360	and also finding something completely out of the Teracle model.
1931360	1935580	So if the Teracle model is more precise, it's good.
1936220	1941500	And so, as I said, benchmark shows that in every case,
1942060	1944600	SCALD actually outperformed everything we tested.
1944680	1948300	It's not to say there is not a better way, but this is working for us.
1948300	1950820	And this is good enough, as we will see.
1950920	1954540	So we came to favor this thing because it's also quite fast.
1954740	1959080	It takes, I don't know, about 10 minutes to explain a network.
1959160	1965840	Okay, now let's explain in greater detail how you go from model to leakage map.
1965840	1967900	The question is how you go from leakage map to code.
1968160	1974820	Well, for that, as I mentioned, we have an emulator, which is based on Unicorn and Rainbow.
1974820	1978980	And basically, we run it with a firmware on the CPU.
1979280	1986580	And we basically have a state automaton to try to emulate what's happening during the leakage map.
1986580	1990660	But the idea is you want to do AS start, run the AS, AS stop,
1990660	1995120	and basically pick up what is in sync with the leakage map.
1995320	1999600	And then what happens then is you get mapped ASM.
1999600	2004380	So what you get is you get, okay, this cycle maps to this time,
2004380	2011640	this point in the track map to that cycle, that cycle map to this specific CPU instruction.
2012020	2017020	And then what we do is when we have a CPU instruction, we build a tree.
2017020	2025820	And the tree, we bubble up the instruction to a given code line using the debug symbol of our firmware.
2025820	2031100	The firmware we run, the firmware we have is in debug mode.
2031100	2035160	Again, we're back to this idea that this is a tool for developers.
2035160	2040540	So when you test for leakage, you can compile with the debug symbol because you don't try to harden it.
2040540	2041840	We just want to debug it.
2041840	2047160	So we have the debug symbol which helps us to go back from the instruction back to the line of code.
2047160	2051100	And hopefully, that gives us an idea of where to map the code.
2052440	2058200	So there's a theory, but we haven't told you or haven't shown you if it really works in practice.
2058200	2064480	And the thing is, before I do that, I want to be on phase three of this project.
2064480	2073520	The first one is, we spend a lot of time talking about explainability because if we don't have extremely precise explainability technique,
2073520	2083980	which exactly pinpoint what point in the trace is responsible for the leakage, we're going to fail.
2083980	2093080	We're going to fail because most instructions on ARM are two, maybe three, maybe four seconds long at most.
2093080	2097480	Not at most, but one to two instructions for an additional standard.
2097700	2100420	So it's literally four to eight points.
2100660	2104660	Like our margin of error is maybe one point, but that's about all we get.
2104660	2110520	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,
2110520	2113520	it's meaningless for us because then it might be three instructions.
2113520	2116340	And those instructions might belong to a different line of code.
2116340	2119560	So basically, your analysis is completely botched.
2119880	2126020	At the same time, we need to have an emulator, which is also single cycle precision,
2126020	2131460	because what happens is, if you do not take into account, let's say, pipeline flush,
2131460	2138000	if you don't take into account the CPU pipeline size and things like that, you get it wrong.
2138040	2140960	You get it wrong because you're going to shift everything by, let's say,
2140960	2146580	by one cycle for each addition, then your whole traces is completely shifted.
2146580	2151300	And then even if your leakage mapping is good, you get somewhere in the code which is not relevant.
2151300	2157380	So you need cycle precision emulator, cycle precision, single point precision explanation.
2157520	2162980	So you need something extremely precise. This is very, very much a precise work.
2162980	2166140	And then on top of that, you need a bit of computation.
2166140	2171000	Again, as I said, you need to generate about a... we use, I think, a one million data point,
2171000	2176500	something like that. And then even for the explanation time, we use 60,000 traces.
2177080	2180520	You need 16 models. As I mentioned, you can shorten the time, of course,
2180520	2183200	by using good models who convert very quickly.
2183680	2187500	You need to generate 16 explanations for all those models in your trace,
2187500	2189040	and then you need to map everything.
2189460	2195100	So with our optimization, that will take you a day or so of work.
2195100	2199860	And, of course, as I said, most of it is parallelizable because the 16 models
2199860	2203420	and 16 explanations can be run on distinct CPU.
2203420	2207260	So you can make it 16 times faster.
2207340	2212660	So that's really good because we want to use that as a fast iterative tool for developers.
2213520	2218600	All right. So at this point, you're like, OK, he gave me a long speech of why it's really hard.
2218600	2223080	So probably they failed. And it's really, really hard because, yeah, emulating a CPU is hard.
2223080	2227180	And I'm telling you it's true. I don't think we have perfect emulation of CPU.
2227180	2235200	I think we have very precise emulation of the instruction we need for AES.
2235200	2243080	In particular, one thing we don't have, and disclaimer, is we don't have implemented mapping for divide.
2243260	2252320	Why? It's because division actually takes a lot of cycle and a very different branch of cycle on ARM CPU.
2252320	2259240	So we don't really know what to do there. So that's only working for now for AES and for transparency.
2259440	2264660	That being said, if we try to apply what I said to our model,
2264660	2271140	what we expect to see in the theoretical sense is we're supposed to... if the model is targeting sub-byte in,
2271140	2277380	then it must exploit something in the add-on key because add-on key is where you do...
2277380	2282420	the key exploits the plaintext. So it must have most of the... mainly cache should be there.
2282420	2289260	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.
2289520	2293420	And so that's what the schedule output looks like. It's a terminal thing.
2293420	2299960	You basically run it and at the end spit out this, as I said, tree, which maps cycle instruction,
2299960	2305400	which is not displayed for visibility, to code line, which is basically numbers.
2305400	2312380	And then I filter everything which is not leaking. And then what this mapping tells you is, yes,
2312380	2317860	the main leakage is on line 2.13 of add-on key. So that's promising.
2317860	2324500	It also has, interestingly enough, a second leakage, which is later on into the cipher functions.
2326660	2333700	So what is the line 2.13, right? Well, the good news is it's exactly what we predicted.
2333700	2339920	This is exactly the line in the whole code that you can find on GitHub,
2339920	2345040	which is exactly where the key is XORed with the plaintext.
2345240	2352200	So the model, and Scaled in general, really clearly is using what a theorem would predict,
2352200	2356760	which is there is a leak in that specific line because they are doing...
2357340	2362340	they are showing the value of the register with some assignment.
2362540	2365700	And so this is what it is. So that's a success.
2365700	2372480	That's what gives us confidence that what we do works in practice. It's really giving us interesting results.
2372740	2378360	I will not claim it works in every case. I'm sure that with more complex implementation,
2378360	2383600	like masked AES or more complicated security, the result might be drastically different.
2383600	2389560	As I said, our emulator did not fully emulate all the operations it can do on ARM.
2389640	2394180	There is still a lot of uncertainty, but however, it works.
2394380	2398460	I think it's a very promising step towards the right direction of having tools
2398460	2402860	who go back from leakage to exact line of code.
2402860	2406020	As far as we can tell, it's the first time it has ever been done.
2406500	2410120	Back to the secondary leakage, I don't have a good explanation for it.
2410120	2417120	The best thing I can come up with today is that it probably went when some of the registers are unloaded.
2417120	2422760	And so this is where it started with a mixed column, if you look at line 371.
2423200	2428480	So maybe that's what happened, it's unloading some of the registers and then going back.
2428480	2433780	We need a little bit more analysis for that, but basically it will be interesting to know why there is another leakage.
2434040	2439560	So hopefully today I showed you how we use Scalar to automatically isolate the number of codes
2439560	2445480	and show you how it works in practice and show you concretely what is the benefit of the tool.
2445780	2450500	And really our hope is this type of tool, we keep building it and we get feedback from the community
2450500	2457760	to build something which will empower people who develop secure hardware to quickly figure out and patch
2458660	2464240	where the leakage are coming from so we can develop stronger crypto in an easier way and a faster iteration
2464240	2468300	so we all benefit from stronger, more secure devices.
2469480	2477120	And to take over the talk, as I said, as we discussed last year, machine learning is a way to automate
2477720	2482300	such an attack and you reach state-of-the-art with it so it's really one of the most...
2482880	2489880	it's at the forefront of such an attack and this year we flipped the use case on its head
2489880	2493620	which is really what was the intent of the project from the onset two years ago
2493620	2499880	which is to try to use all those knowledge to actually help developers building better tooling
2499880	2504780	for them to reduce the cost of developing secure implementation and make them better.
2505180	2510160	So that being said, this is a very, very new field, a very exciting field with a lot of ideas,
2510240	2514700	a lot of energy around it and it can really use more people interested in it
2514700	2519380	so if you have some interest into crypto, into machine learning, it's a great time to get in
2519380	2523440	and work with the community on this type of ideas.
2524420	2528080	Thank you so much for attending this virtual talk. I wish it would be in person.
2528080	2532260	I'm going to miss DEF CON as you probably do. I hope you're all well
2532260	2538300	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
2538740	2546480	modulo some delay to provide you information about what we do on such an attack on the website.
2546480	2550220	Hopefully we'll have an official project website in the future as well.
2550220	2556580	Thank you so much for listening to this talk and then do not hesitate to reach out on Twitter
2556580	2562460	or by email or any other means. Happy to answer questions. Thank you so much. Bye.