[00:08.320 --> 00:12.960]  Are you seeing us, sir?
[00:17.620 --> 00:19.880]  Okay, we're good.
[00:20.620 --> 00:24.520]  Alright guys, we have Ellie Burstyn
[00:24.520 --> 00:28.960]  here to talk to us today about Hacker's Guide to Side Channels.
[00:29.060 --> 00:32.340]  And with that, I'd like to turn it over
[00:32.340 --> 00:36.000]  to you to have any sort of first questions, or first answers.
[00:36.000 --> 00:39.120]  And we'll start taking questions on the Discord channel.
[00:39.120 --> 00:43.120]  So, thank you for joining us. And any sort of
[00:43.120 --> 00:44.420]  open remarks or anything?
[00:46.920 --> 00:51.380]  Thank you for watching the talk. I would have loved to do it in person.
[00:51.380 --> 00:55.200]  I kind of miss the DevCon ambience, but I hope we'll try
[00:55.200 --> 00:58.740]  to have a good chat, ask anything you want, and try to do my best.
[00:59.320 --> 01:01.620]  And again, thank you so much for watching the talk.
[01:03.740 --> 01:06.140]  So, I guess I'll start off.
[01:06.140 --> 01:10.020]  I think you did a good job
[01:10.020 --> 01:14.260]  in the talk, talking about the sort of why of machine learning, and why
[01:14.260 --> 01:16.760]  the model predicted... or why
[01:17.960 --> 01:21.960]  machine learning decided the way it decided,
[01:21.960 --> 01:25.200]  if that makes sense. And why the model predicted what it predicted
[01:26.020 --> 01:30.020]  in order to understand how a defender would react to that.
[01:30.020 --> 01:33.540]  I don't know if you want to elaborate on that talk. I've never sort of...
[01:33.540 --> 01:37.340]  I've never thought of machine learning...
[01:37.340 --> 01:40.980]  you think of machine learning, judging it on what the outcome of it is,
[01:40.980 --> 01:45.340]  not what led to that outcome, and what
[01:45.340 --> 01:49.240]  defense to build from it. So, I don't know if you want to comment on that
[01:49.240 --> 01:53.360]  thought, or if it even makes sense, what I just asked.
[01:53.420 --> 01:55.280]  No, it does. It does. It does.
[01:56.700 --> 02:01.100]  I think we have a lot of security tools for debugging.
[02:01.100 --> 02:05.280]  I think if you want to debug a C++ program, we have debugger.
[02:05.740 --> 02:09.120]  We have Python debugger, C++ debugger.
[02:09.980 --> 02:13.260]  Most of the things we can debug, because we have a way
[02:13.260 --> 02:17.180]  to introspect where the bug is triggered.
[02:17.180 --> 02:20.880]  The systems, the entire stack is developed around
[02:20.880 --> 02:25.540]  error handling. The problem is how the crypto is.
[02:25.540 --> 02:28.900]  You run a crypto algorithm on the hardware, and
[02:28.900 --> 02:34.020]  you have no idea why information is taken.
[02:34.060 --> 02:35.900]  You have a leak. You know that the machine learning
[02:35.900 --> 02:40.680]  is finding the correct key, or the correct attack point.
[02:40.940 --> 02:44.800]  And you're like, OK, I developed this kind of implementation, and we do at Google
[02:44.800 --> 02:49.540]  have our own cryptographic chip, so that's something we're very concerned about.
[02:49.540 --> 02:53.080]  And everyone who has a crypto chip is interested in that question of, OK,
[02:53.080 --> 02:56.960]  you have a leak, but then what? And prior to machine learning,
[02:56.960 --> 03:00.740]  we didn't have a technique, or we didn't have a tool,
[03:00.740 --> 03:05.020]  where you can ask, why? Why do you predict what you do?
[03:05.300 --> 03:08.280]  This is kind of like a crazy thing about the machine learning thing.
[03:08.280 --> 03:12.700]  It does things which we can't do otherwise. It's not ideal,
[03:12.700 --> 03:16.380]  because, you know, we all say, well, machine learning is a black box. That's completely true.
[03:16.640 --> 03:20.620]  But the only thing we have, which is like, OK, can you please tell me
[03:20.620 --> 03:24.620]  why? The why is a little bit easy,
[03:24.620 --> 03:28.680]  but it's like, why? And then we thought, OK,
[03:28.680 --> 03:32.900]  since we moved from site-generator using statistical estimates to machine learning,
[03:32.900 --> 03:35.800]  and we talked about it last year at DEF CON, it works really well.
[03:36.000 --> 03:40.480]  Can we go one step further and try to also ask the model why? And then you can do that.
[03:40.480 --> 03:44.440]  And as I said, it's very, very brittle. You have to be
[03:44.440 --> 03:48.000]  super, super precise, and we make it work for one implementation.
[03:48.220 --> 03:50.880]  And, you know, it's a tool, so obviously we're going to show you the best case.
[03:50.880 --> 03:54.280]  The truth of the matter is, you know, you have to really be super precise,
[03:54.280 --> 03:59.040]  which is like CPU instruction precise, so it's not super robust just yet,
[03:59.040 --> 04:02.840]  but you can do that. And I think that's the only tool in the world who can do that.
[04:02.840 --> 04:07.140]  That's why Scaled is one of its kind. It's the first generation of it.
[04:07.340 --> 04:10.300]  You know, five years, ten years from now, we'll be laughing at it and be like, OK,
[04:10.300 --> 04:14.960]  we've got a way to do it, I'm pretty sure. But it was
[04:17.540 --> 04:19.200]  two crazy years of
[04:19.200 --> 04:22.860]  brainstorming and trying ideas until we came up with an idea of doing it.
[04:22.860 --> 04:27.340]  It came out of necessity. It came out from our project team inside Google
[04:27.340 --> 04:31.260]  of like, OK guys, you make better attacks, which was not the goal,
[04:31.260 --> 04:34.940]  but the goal of our whole project was to make a better world, like a more secure world.
[04:35.100 --> 04:38.700]  I didn't have to pitch a choir, and then
[04:38.700 --> 04:42.960]  we really wanted to make a tool for our engineering team of like, and around the world of like,
[04:42.960 --> 04:47.520]  OK, here's a tool you can use, here's a tool lab, here's a debugger for hardware crypto.
[04:47.520 --> 04:51.600]  And it just doesn't exist. So that's where it comes from.
[04:51.640 --> 04:55.540]  And without machine learning, it doesn't work, but without the relations, it doesn't work, and without the community,
[04:55.540 --> 04:59.620]  it doesn't work. We use a lot of the technology behind the scenes, like Unicorn.
[04:59.760 --> 05:03.800]  And we had a pretty good talk today about Unicorn as well. A lot of people are using Unicorn,
[05:03.800 --> 05:07.180]  which is a CPU emulator, which is very close to the community, so we are
[05:07.180 --> 05:11.260]  standing on shoulder of giants, which is bringing some of the interesting
[05:11.260 --> 05:14.160]  twists to it. That's what it is.
[05:15.520 --> 05:19.240]  Great. So actually, just jumping off what you said,
[05:19.240 --> 05:22.360]  are people actually using this to
[05:23.900 --> 05:26.380]  help identify side channels yet, or
[05:26.380 --> 05:28.660]  have you been approached by anyone? No, not yet.
[05:30.800 --> 05:34.160]  To be clear,
[05:35.380 --> 05:38.380]  we had a lot of debate actually internally, because
[05:38.380 --> 05:41.760]  it's really super out of the press. I would say the initial
[05:41.760 --> 05:46.180]  complete success was probably one or two weeks old.
[05:46.180 --> 05:49.640]  We knew it was somewhat working, but we didn't get it to work as
[05:49.640 --> 05:53.780]  clearly as it should. It took like, I think maybe 24 hours before
[05:53.780 --> 05:57.760]  I recorded the talk to be clear. But we saw that
[05:57.760 --> 06:01.840]  DevCon is virtual, we really want to contribute, we really want to be part
[06:01.840 --> 06:05.200]  of the community. Usually we're not really good at
[06:06.040 --> 06:10.260]  things ahead of what we do, but this year we saw that we wanted to really show you
[06:10.700 --> 06:13.840]  the trading engine, what we were working on as a way to
[06:15.740 --> 06:18.520]  participate and to be part of the community.
[06:18.620 --> 06:22.720]  So, no, it's not there yet. The research effort is not there yet.
[06:22.760 --> 06:26.280]  I'm sure the COVID question is going to come, so I'll answer. Yes, the code will be public
[06:26.280 --> 06:30.980]  next week. I'm still cleaning up the GitHub to tell you how new it is.
[06:31.300 --> 06:34.900]  But we went for, here is something new and exciting that we work on.
[06:34.900 --> 06:38.560]  You guys might get a kick out of looking at it and be inspired,
[06:38.560 --> 06:42.480]  and that's what we go for. So, the talk, sometime I'm bumping into the middle of it.
[06:42.700 --> 06:45.840]  Sorry about that, too. I tried to record it with the door closed.
[06:45.840 --> 06:50.220]  In California, it's like 28 degrees in the room when I try to record, so I was
[06:50.220 --> 06:54.540]  straining a little bit. I apologize also for my English. But, yeah, we really tried to do
[06:54.540 --> 06:58.300]  like, this is the state mode talk, which is like, we do show you
[06:58.300 --> 07:02.260]  bleeding edge. Like, it's a true, you know, very old DevCon spirit.
[07:02.260 --> 07:06.320]  Like, this is new, we're here to transform it. That's what it was. So, no, it's not here.
[07:06.320 --> 07:07.880]  Absolutely not.
[07:12.300 --> 07:14.100]  That's great.
[07:14.740 --> 07:18.380]  So, the example we're using
[07:18.380 --> 07:21.220]  were mostly around power, if I understood the
[07:22.120 --> 07:26.540]  presentation right. And, you know, you mentioned other side channels,
[07:26.540 --> 07:30.460]  you know, heat, emissions, timing, etc.
[07:30.460 --> 07:33.760]  I mean, do you see these techniques would apply to all those, or
[07:33.760 --> 07:37.980]  there wasn't anything unique to the instrumentation
[07:37.980 --> 07:40.920]  you used, right? No, I don't see there's anything
[07:41.720 --> 07:45.840]  special to it. I never used, I said, I don't
[07:45.840 --> 07:50.000]  know if anyone ever used heat. I would be super curious if someone knows about
[07:50.200 --> 07:54.140]  a heat attack, timing attack, which is super, super interesting.
[07:54.140 --> 07:57.940]  I've never seen one. Like, in crypto, they might exist,
[07:57.940 --> 08:01.760]  I don't know. But we thought about, yeah,
[08:02.180 --> 08:04.540]  magnetic, I think, is one of the big deal.
[08:07.580 --> 08:10.140]  We wanted to do this here, to be clear.
[08:10.600 --> 08:13.500]  And extend what we do from power to EM as well.
[08:13.880 --> 08:17.780]  The truth of the matter is, we cannot go to the office, right, doing remote work in our team,
[08:17.780 --> 08:21.720]  as many of us are doing in the community, and we don't have
[08:21.720 --> 08:25.700]  access to our equipment, right. The only thing we can really do is power, because that's what is
[08:25.700 --> 08:29.740]  plugged into our lab. And the only thing we can access remotely to do
[08:30.260 --> 08:34.220]  is EM. You have to literally have an EM table, and you have to be on top of the chip.
[08:34.460 --> 08:37.320]  And that is not doable in the near future.
[08:37.320 --> 08:41.600]  So, we'd love to do EM. I think the next big target
[08:41.600 --> 08:45.640]  is that. You would do, maybe timing.
[08:45.640 --> 08:49.580]  Timing might work too, probably. I think there is a few papers coming out this year
[08:49.580 --> 08:54.220]  from other groups on machine learning and timing attacks for
[08:56.320 --> 08:57.460]  Parasite, I believe.
[08:57.840 --> 09:01.920]  I don't think we'll be able to cure it, so I think it will most likely show that you can use machine learning for that.
[09:02.000 --> 09:04.780]  So, as I said, machine learning is an easier way to
[09:05.660 --> 09:09.320]  take over such an attack for hardware in the next 2-3 years
[09:09.320 --> 09:13.280]  than when it's going to do it. We just happened to be the first few groups
[09:13.280 --> 09:15.480]  who are doing it. There are other groups in France.
[09:17.240 --> 09:21.240]  There's a German group as well who is doing some of it. Some vendors
[09:21.240 --> 09:25.160]  are taking some of the research and putting it into products. I think that's where it's going to go.
[09:25.160 --> 09:29.280]  But I think most people are on the power train for now.
[09:29.300 --> 09:32.440]  Maybe a little bit of timing attack is pretty new this year.
[09:32.720 --> 09:34.400]  I guess the end is the next.
[09:34.480 --> 09:41.180]  Yeah, I was wondering that too. It's kind of, as you were saying, you built
[09:41.180 --> 09:44.740]  your model, I guess, using mostly an emulator. How well
[09:44.740 --> 09:49.220]  does that scale then to other hardware? Is it kind of the research you've
[09:49.220 --> 09:53.280]  done, it's that one sample? Or do you think that you're going to need to build your machine learning models
[09:53.280 --> 09:57.140]  for different types of processors or setups, right? Does that make sense?
[09:57.400 --> 10:01.120]  Yeah, so for the attack side, we know it works.
[10:01.420 --> 10:04.920]  I mean, I hope it's not a unique paper, but
[10:05.420 --> 10:09.220]  since last year we've been working. The last three years we have collected a massive
[10:09.220 --> 10:13.420]  set of data sets that we really hope to publish.
[10:13.420 --> 10:17.580]  I'm not going to give a date at that point. Last year I said very soon, and it didn't happen this year.
[10:17.800 --> 10:21.160]  Or the next year we have. But yes, we have that for
[10:21.160 --> 10:25.200]  multiple data sets, multiple hardware that works. For the emulation side,
[10:25.680 --> 10:29.200]  the other side, which is not the machine learning side, the dynamic analysis where we need to
[10:29.200 --> 10:33.200]  be site-precise, we don't even have a normal. And the thing
[10:33.200 --> 10:36.560]  is, Intel is, for example, out of the question because
[10:37.160 --> 10:41.220]  they have a predictive pipeline, so we don't even know, like, depending on
[10:41.220 --> 10:44.920]  how the Intel predictive pipeline will work or the flush pipeline will work,
[10:44.920 --> 10:49.120]  the number of instructions is completely non-deterministic. Or at least to the point where, in our
[10:49.120 --> 10:53.380]  poor brain, we're not going to be able to do it just yet. So if your CPU is too complicated,
[10:53.380 --> 10:57.200]  I don't think we can. Reduce set instructions should work,
[10:57.200 --> 11:00.980]  I guess, but like I said, we don't even have a device now because
[11:00.980 --> 11:05.480]  it's like, oh, it's between, I don't know what the range is, 2 to 12 cycles.
[11:05.480 --> 11:09.200]  So we have to make an estimated guess. So it works
[11:09.200 --> 11:12.800]  for ARM, mostly embedded stuff, I assume. Smaller
[11:12.800 --> 11:17.260]  power would work too. But yes, the emulation side of it is
[11:17.260 --> 11:21.100]  hard because if you're off, you know, if your
[11:21.100 --> 11:25.140]  machine learning is correct, it finds the attack, then if you're off
[11:25.140 --> 11:29.220]  for the cycle for the emulation, you end up, I don't know, like, 6, 12, 15,
[11:29.220 --> 11:33.160]  100 cycles left or right, and then you're on the wrong
[11:33.160 --> 11:37.340]  line of code, right? The line of code that I said is true for instructions,
[11:37.340 --> 11:40.440]  so you might have, you know, you might get lucky if you're a little bit slowly, but
[11:40.440 --> 11:45.280]  that margin becomes terrifyingly hard. And similarly, there is
[11:45.380 --> 11:49.360]  a back point at the end of the... you can also apply the end
[11:49.360 --> 11:53.000]  of the implementation, not the first round, but the end. And then, again,
[11:53.000 --> 11:56.960]  at that point, every error is compounded, right? So the further you
[11:56.960 --> 12:01.660]  undertrace on the right side of this, the more you're going to
[12:01.660 --> 12:04.960]  have a chance of mixing it up. So yes, we choose easy
[12:04.960 --> 12:09.700]  case, which is like very well-defined ARM, which is a very small set of instructions,
[12:09.700 --> 12:13.080]  well-defined, well-documented, on an easy C
[12:13.080 --> 12:16.360]  non-vectorized, because that's the easy case.
[12:17.260 --> 12:20.880]  Harder case would be like more features of engineering. I think
[12:20.880 --> 12:25.300]  the people in the committee are interested to help us improve the analyzer
[12:25.300 --> 12:28.800]  or add more targets. It's probably doable, it's just going to be interesting
[12:30.180 --> 12:33.120]  reversing engineering exercise, right? And that's what people
[12:33.120 --> 12:37.220]  put at hardware. It's fun to do, it's just, it's going to be quite worse.
[12:38.640 --> 12:40.140]  It's a really good question.
[12:41.820 --> 12:44.200]  Yeah, so, I mean, the attacks
[12:44.200 --> 12:47.160]  themselves are pretty hard, so it goes to show that
[12:47.160 --> 12:51.160]  the defensive analysis would be just as hard, right?
[12:54.160 --> 12:56.260]  Yeah, I mean, we know
[12:56.260 --> 13:00.260]  that hardware, I mean,
[13:00.260 --> 13:04.640]  we know that stationary attacks are inevitable, right? Almost inevitable.
[13:04.640 --> 13:08.160]  There are defenses which might exist, like doubling the bus for
[13:08.160 --> 13:12.080]  power supply, power attack, but that's not going to be implemented
[13:12.080 --> 13:16.360]  in hardware. It's too expensive or too costly or too big.
[13:16.720 --> 13:20.360]  So, everything is inevitable to size your attack to an extent.
[13:20.640 --> 13:24.360]  The question is, how can we make it right? There are
[13:24.360 --> 13:27.500]  really cool set of work done
[13:28.200 --> 13:32.000]  mostly by the French ANSI on MASSKS
[13:32.000 --> 13:36.580]  which is kind of like the way you make it harder. You can also make it slower.
[13:37.260 --> 13:40.280]  So, the question is, how slow can be hardware
[13:41.380 --> 13:44.740]  encryption, right? The question is, how many milliseconds can you tolerate?
[13:45.100 --> 13:48.560]  The reason why I mention that is, if you use security keys, right,
[13:48.560 --> 13:52.580]  we create security keys, they use NFC. And the problem with NFC,
[13:52.580 --> 13:56.500]  NFC is super fast and super low power. So, now, in those settings,
[13:56.500 --> 13:59.680]  making a super resilient implementation is going to be challenging.
[13:59.920 --> 14:04.720]  So, being said, this is not AES as we show, but even for that
[14:04.720 --> 14:08.860]  you cannot switch out. If you want APK, also you cannot switch out.
[14:10.180 --> 14:12.280]  Well, I don't have a lot of time.
[14:12.520 --> 14:16.200]  I don't have a lot of power. And with more computation to
[14:16.200 --> 14:20.700]  harden my thing, that becomes kind of impossible. So, there will always be a trade-off, right?
[14:20.700 --> 14:23.640]  And as long as there is a trade-off, there is a vulnerability.
[14:23.960 --> 14:28.640]  So, you know, Tyler's channel attack is probably the most powerful
[14:28.640 --> 14:32.180]  attack you can do against cryptos these days because this is the one where we know
[14:32.180 --> 14:35.380]  we cannot solve it. So, interesting.
[14:35.380 --> 14:37.600]  It's an interesting space.
[14:37.840 --> 14:43.100]  Pretty interesting.
[14:43.400 --> 14:47.600]  Yeah, and I'll say, I really appreciated your talk, too, how you went through the different steps.
[14:47.600 --> 14:51.920]  It was very informative and instructive. Like, even just mentioning explainers,
[14:51.920 --> 14:56.860]  you did a very good job of explaining everything and really showing the real world examples.
[14:57.140 --> 15:00.540]  You say, though, you say side-channel attacks are really important for encryption.
[15:00.540 --> 15:04.080]  How did you get into the side-channel attack space? What drew you to that?
[15:04.080 --> 15:09.640]  Was it the encryption aspect? How did your research end up on side-channel attacks?
[15:10.700 --> 15:12.080]  Oh, wow.
[15:14.850 --> 15:16.410]  That's a hard question.
[15:16.850 --> 15:22.550]  I think what happened is
[15:23.350 --> 15:25.950]  before, I always did cryptanalysis.
[15:27.390 --> 15:30.070]  People might or might not remember it, but
[15:30.530 --> 15:35.010]  a few years back, we announced the first collision on SHA-1.
[15:35.750 --> 15:39.550]  And we did it all at that time.
[15:41.230 --> 15:43.110]  And it took us a while.
[15:43.110 --> 15:46.190]  It took us a while to do it. Breaking SHA-1 in collaboration
[15:46.190 --> 15:49.230]  with Mark Stevens, the CWI, took three years.
[15:49.610 --> 15:53.550]  Most people don't realize that sometimes when we do talk, it's like, oh, that's great. That's nice.
[15:53.550 --> 15:58.250]  It took three years of effort for us, and I think Mark spent almost ten years on it.
[15:58.250 --> 16:01.170]  So you get out of breaking SHA-1
[16:01.910 --> 16:05.910]  I mean, putting it in practice, it was broken by one, but like
[16:06.470 --> 16:09.990]  providing the first collision, and then, as I said, in 2015
[16:11.190 --> 16:14.370]  we did the first collision. We showed these two PDFs
[16:14.370 --> 16:18.750]  which are about to send SHA-1, and then the world did break SHA-1, which was our goal.
[16:19.530 --> 16:22.490]  Interestingly enough, the backstory, the reason why we decided
[16:22.490 --> 16:26.430]  to do it is not to do a talk, but because we really wanted to
[16:27.790 --> 16:30.550]  help people realize that they need to move away from it
[16:30.550 --> 16:34.270]  at the time Microsoft, XCOR, did not deprecate it
[16:34.270 --> 16:38.430]  and Firefox was lagging, and it had the immediate effect
[16:38.430 --> 16:41.970]  that both of them immediately deprecated it, so it was like
[16:41.970 --> 16:46.770]  why would you ever go into this crazy amount of money
[16:46.770 --> 16:50.430]  and amount of energy to literally compute
[16:50.430 --> 16:52.790]  all this? And the answer was
[16:55.170 --> 16:57.350]  because, at that time, we wanted to show
[16:57.350 --> 17:00.610]  to the world, it was with both Microsoft and XCOR, and we should
[17:00.610 --> 17:04.990]  treat it seriously. Again, it was important to get this always in the context
[17:04.990 --> 17:08.610]  of our team, the research team,
[17:08.610 --> 17:12.910]  we tried to set up an XOR where people come up to this project and try to figure out
[17:12.910 --> 17:16.450]  if it can help the world. And then we finished that, and we were like, okay
[17:18.510 --> 17:21.030]  what else? And then, so yeah,
[17:21.030 --> 17:23.950]  our first research team is almost a hangover
[17:24.410 --> 17:27.910]  because we had to get professional marketing and we were like, what's next?
[17:28.250 --> 17:31.330]  A piece of crypto, and then we were like, okay what's next?
[17:32.010 --> 17:35.950]  And then we started to talk with the project team, and at that time
[17:37.430 --> 17:40.750]  something called the Titan chip, publicly,
[17:40.750 --> 17:44.530]  is developed by Google. It's Google's own crypto chip. And the crypto chip
[17:44.530 --> 17:48.150]  we talked to the hardware engineer, and they told us, well, no.
[17:48.690 --> 17:51.650]  So this crazy idea, we come up with one
[17:52.270 --> 17:56.190]  paper from the French agency, which is the French
[17:56.190 --> 18:00.270]  control agency specializing in crypto. They have this very, very interesting work
[18:00.270 --> 18:04.190]  on machine learning and crypto, you should check it out. And I was totally
[18:04.190 --> 18:08.050]  in love with the idea. The internal team was very interested in
[18:08.050 --> 18:11.930]  having more resources, and then we realized
[18:11.930 --> 18:16.050]  it's very, very powerful, very interesting. It's played well into what Google do,
[18:16.050 --> 18:19.930]  which is machine learning at the time, it's here. It plays well
[18:19.930 --> 18:23.870]  into core and fundamental research that we do.
[18:23.970 --> 18:27.670]  It plays well with... that's what we decided to go for. Honestly, we got
[18:28.190 --> 18:31.110]  from our project team, so it was
[18:33.370 --> 18:36.210]  completely serendipitous, and has been seen in research more like
[18:36.210 --> 18:39.270]  you know, talking to people, and it's like
[18:39.730 --> 18:44.030]  something like that. You want to talk, you get inspired by other people, you build on
[18:44.030 --> 18:48.610]  other people's work or ideas, and we all keep it to push it further.
[18:48.910 --> 18:52.250]  So I think that's what it was. I think that was this idea
[18:52.250 --> 18:56.370]  of come from other people, and take credit for it all.
[18:56.390 --> 19:00.310]  We met a lot of wonderful people from Ledger,
[19:01.450 --> 19:04.050]  from Chipwister, you know, Colleen, and many Chipwisters
[19:04.050 --> 19:07.730]  by the way, the scaffolding committee, the institutional community,
[19:07.730 --> 19:11.630]  we also have a lot of time to help us, give us pointers
[19:11.630 --> 19:13.070]  early days.
[19:13.070 --> 19:17.070]  So we're glad that now we're back.
[19:18.470 --> 19:23.610]  Great, so we have a question from the audience. Apart from approving the emulation,
[19:23.610 --> 19:27.430]  what do you see as the next step in this field of side-channel detection?
[19:30.970 --> 19:31.490]  Detection...
[19:34.470 --> 19:36.230]  That's a great question.
[19:37.950 --> 19:39.370]  I think there are
[19:39.370 --> 19:39.870]  ...
[19:43.230 --> 19:45.750]  I think it goes hand-to-hand with
[19:47.050 --> 19:51.270]  better attack. Again, we can only explain what we can attack.
[19:51.270 --> 19:55.470]  I think we have a few working streams on
[19:55.470 --> 19:58.870]  public key, and a few working streams on other algorithms.
[19:58.870 --> 20:03.210]  I think that will be interesting to do. We're always looking for people
[20:03.210 --> 20:07.370]  who are willing to work with us, because it's a very, very big...
[20:08.950 --> 20:11.690]  I won't say difficult, but it's a lot of grind
[20:11.690 --> 20:15.710]  to create the data, and to do the machine learning, and that sort of thing.
[20:15.710 --> 20:19.350]  So if people are interested to collaborate, we're always up for it, because
[20:19.350 --> 20:23.290]  it's a little bit like, figure out what to do, it's hard. Last year,
[20:23.290 --> 20:26.730]  when I come, I go, it's so hard to do the IAF model. This year, after a year of
[20:26.730 --> 20:31.190]  refining the machine learning model and our process, we can basically do it in 10 minutes.
[20:31.190 --> 20:34.090]  So we went from 5 hours to 15 minutes
[20:35.310 --> 20:38.230]  by getting just mechanically better at it.
[20:38.230 --> 20:41.210]  I think it's going to be the same for the other algorithms.
[20:41.490 --> 20:46.030]  So I really view that. I think we're also going to view, I hope,
[20:46.030 --> 20:50.290]  people being creative for it. I don't know.
[20:50.630 --> 20:53.930]  I would imagine you can do that timing attack. Some people mentioned
[20:53.930 --> 20:57.450]  cache line as an idea. I found that quite interesting.
[20:57.670 --> 21:02.030]  There is a holy grail of Intel HDX.
[21:02.030 --> 21:06.230]  I mean, Enclave is also using crypto. It is crazy
[21:06.230 --> 21:10.330]  hard to attack, because it's literally baked into the Intel CPU.
[21:10.850 --> 21:13.990]  However, no one knows if machine learning can do it or not.
[21:13.990 --> 21:18.590]  Some people we talked to say yes, it's probably doable. I don't know. I never do it.
[21:18.910 --> 21:22.230]  We don't have necessarily the time to do it by ourselves. We're happy to
[21:22.230 --> 21:26.170]  contribute, but that's something which is interesting line of research. I think Enclave is
[21:26.250 --> 21:30.130]  a big deal. Other algorithms are a big deal. But also
[21:30.130 --> 21:33.590]  we can think of crazy things. Everything which is timing sounds a bit bad.
[21:34.370 --> 21:38.130]  I would not be surprised if someone even came up with a crazy idea of how to do it
[21:38.130 --> 21:42.030]  for Bitcoin wallet transactions, or even
[21:43.790 --> 21:46.430]  what would be another interesting step. SQL injection.
[21:46.530 --> 21:49.410]  We have a lot of blind SQL injection. Maybe we can
[21:50.210 --> 21:54.390]  get more out of the timing. We can make more out of the timing that we think we can.
[21:55.570 --> 21:58.290]  It's unclear. I mean, most of them should have been fixed,
[21:59.110 --> 22:02.670]  but yeah, I don't know. That's a lot of room,
[22:02.870 --> 22:06.090]  a lot of creativity. It depends on people's taste.
[22:07.350 --> 22:08.310]  I'm not sure.
[22:09.590 --> 22:14.330]  So you mentioned a paper is coming out. Do you have an estimate on when you're going to be
[22:14.330 --> 22:18.330]  done with that? I'm not going to jinx it, Matt. I'm not going
[22:18.330 --> 22:22.390]  to do that. Last year I said it's going to be soon. The draft is still on my
[22:22.390 --> 22:25.730]  desk. And for the schedule paper, I'm going to be completely
[22:25.730 --> 22:29.450]  honest. I told you we rushed to do it for DEF CON. We really wanted to show you
[22:29.450 --> 22:33.590]  Building Edge. Literally the paper is not ready yet. The next step for us is
[22:33.590 --> 22:37.750]  to put everything on GitHub. I'll post the link on Twitter
[22:38.390 --> 22:39.690]  hopefully next week.
[22:41.510 --> 22:45.490]  And then we're going to want people to play with it. We'd rather provide
[22:45.490 --> 22:49.690]  incomplete stuff to people to play, because last year we did
[22:49.690 --> 22:53.650]  the reverse. We thought we were going to hold, hold, hold, and get everything at once
[22:53.650 --> 22:56.970]  and it didn't work out. So this year, we're switching the strategy.
[22:57.370 --> 23:02.010]  I'm going to release early. Imperfect, but early. And then the paper will come later.
[23:03.210 --> 23:05.450]  Completely what? But yes, the AES datasets
[23:05.450 --> 23:09.210]  we promised last year are still there. We just haven't got the chance to
[23:10.290 --> 23:14.110]  release them. And then the schedule paper, you'll be able to play with the code.
[23:14.130 --> 23:17.110]  Run the code I showed you. Get the verb I showed you. And then
[23:18.110 --> 23:22.150]  that will be incomplete, because you'll be like, oh, where are the other attack points?
[23:22.150 --> 23:25.710]  Not there yet. Where are the other models? Not there yet. They're going to get there
[23:26.310 --> 23:30.030]  when they can. And I make no promises. Because I can't
[23:30.030 --> 23:33.810]  I don't know what I can keep or not. So I try to be a little bit more
[23:34.450 --> 23:37.470]  realistic this year than last year. I want to achieve
[23:37.470 --> 23:42.270]  good people. I was going to ask the same thing, so it's definitely on folks' minds.
[23:42.390 --> 23:46.370]  We do have a question from the chat. So, you know, are you aware of
[23:46.370 --> 23:50.050]  any side-channel attacks that are found in the wild, right, where attackers are
[23:50.050 --> 23:53.810]  using them? Or is this more of where we're thinking about how to defend against these attacks
[23:53.810 --> 23:56.330]  before, you know, we see them active?
[23:56.750 --> 24:02.070]  Oh, side-channel are everywhere. Side-channel are everywhere. They're like the
[24:02.070 --> 24:04.550]  most prevalent form of attack for hardware.
[24:05.610 --> 24:10.030]  Let me try to figure out which one I can tell you which are pretty interesting. So again,
[24:10.030 --> 24:13.930]  it's not singular. To put one company like this company is bad,
[24:13.930 --> 24:17.910]  because I'm going to use all of them. So I start with one of my
[24:17.910 --> 24:21.790]  favorite companies, which I really like, Ledger.
[24:21.950 --> 24:25.790]  Two years ago, they had away someone from a timing attack on
[24:25.790 --> 24:30.130]  the IoT curve. This was the example I gave at the beginning of the talk.
[24:30.170 --> 24:33.210]  And they were able to recover all the Ledger treasure
[24:34.210 --> 24:37.730]  by Bitcoin private key. So that's a pretty big deal.
[24:38.990 --> 24:41.910]  There was a timing attack on a game console.
[24:42.350 --> 24:45.830]  I think it was streaming on Twitch. I'm not going to give too much
[24:45.830 --> 24:50.890]  detail, but many, many game consoles
[24:50.890 --> 24:53.850]  are protected by crypto.
[24:54.370 --> 24:57.650]  And there was a timing attack to recover some of those secret keys.
[24:57.990 --> 25:00.650]  That was earlier generation. I'm not talking
[25:02.150 --> 25:06.350]  5 or 4 or Xbox One.
[25:06.350 --> 25:08.990]  I'm talking previous generation, but there was a timing attack
[25:08.990 --> 25:12.750]  who were used to recover crypto keys.
[25:12.750 --> 25:17.170]  There was many of them. There was an AES one a very long time ago
[25:17.170 --> 25:21.090]  used by... I believe
[25:21.090 --> 25:24.890]  it was Dan Bernstein on remote AES. There was one
[25:24.890 --> 25:29.050]  on cache line attacks on CPUs.
[25:29.050 --> 25:32.070]  There are so many of them everywhere. Session attacks are
[25:32.730 --> 25:36.670]  so powerful. The most powerful form of SQL injection
[25:36.670 --> 25:40.770]  is binary SQL injection. Sorry, session attack. Binary SQL injection
[25:40.770 --> 25:44.750]  is when you have a SQL injection, but you can't see the output
[25:44.750 --> 25:48.930]  when you trigger. You do it one character at a time
[25:48.930 --> 25:52.690]  and you just look at whether the server responds or not. That's a form of session attack.
[25:52.910 --> 25:56.870]  They are everywhere. It's a super, super practical attack
[25:56.870 --> 26:00.850]  and usually people are really annoyed and say it's not a good attack because it's a known technique.
[26:00.850 --> 26:03.870]  It's not a known technique. It's a known technique. It just happens that it works
[26:05.230 --> 26:08.770]  super, super efficiently on many, many things.
[26:09.770 --> 26:10.970]  Yep.
[26:12.550 --> 26:14.370]  And we have it on
[26:15.950 --> 26:20.830]  physical stuff like electronic locks and things like that.
[26:26.150 --> 26:27.830]  Oh, I forgot.
[26:27.930 --> 26:32.810]  I thought that was the most important one. I'm sorry.
[26:33.630 --> 26:37.030]  Spectre and Meltdown. Right.
[26:37.030 --> 26:40.750]  Spectre and Meltdown. There you go. The thing which completely destroys your CPU.
[26:40.750 --> 26:44.010]  They are a form of session attack. So here you go.
[26:44.190 --> 26:48.950]  As I said, some of the most powerful concrete attacks
[26:48.950 --> 26:52.870]  we've seen in the last few years are session attacks because they are so hard to
[26:52.870 --> 26:55.770]  debug, so hard to pull off, to defend against.
[26:55.770 --> 26:59.690]  Yeah, I think I read something about those.
[27:00.390 --> 27:02.150]  They were kind of big, right?
[27:02.590 --> 27:05.750]  Yeah, I pinned in the chat the
[27:06.830 --> 27:10.030]  article. There's a weird article who can outline that.
[27:10.030 --> 27:13.610]  It would be good to just read up if you guys are interested.
[27:16.030 --> 27:18.410]  I think it's QA. There you go. Thank you.
[27:18.870 --> 27:22.090]  Yep. Yeah, so we've got a couple minutes
[27:22.090 --> 27:25.430]  left. If we have any more questions, let's get them in here.
[27:25.710 --> 27:28.610]  Otherwise, we're going to thank
[27:29.910 --> 27:30.690]  Ellie and
[27:32.870 --> 27:34.630]  let you guys get back to the con.
[27:35.530 --> 27:40.270]  One last one for me. Oh, wait, we actually do have one more.
[27:41.530 --> 27:44.110]  Yeah, so someone who is mainly focused in InfoSec.
[27:44.830 --> 27:48.490]  What kind of background do you think people kind of lend themselves to
[27:48.490 --> 27:51.950]  going towards looking at side-channel attacks and thinking about the research you're doing
[27:51.950 --> 27:55.450]  with being able to detect that in different ways?
[27:57.270 --> 27:58.690]  What kind of background?
[28:00.590 --> 28:01.910]  It varies.
[28:04.510 --> 28:06.930]  We have some people who come from
[28:09.050 --> 28:09.930]  radio.
[28:11.230 --> 28:14.290]  For those who don't know, the first initial side-channel attack was actually
[28:15.910 --> 28:19.250]  in the 1940s or something like that, where they had a typewriter
[28:19.250 --> 28:23.490]  and the guy was having an oscilloscope, and then he sort of blinked on the oscilloscope
[28:23.490 --> 28:27.490]  and realized that there was something. And then the Russians put a
[28:28.670 --> 28:31.470]  user to spy onto people
[28:31.470 --> 28:36.070]  by looking at vibrations. So that's super old stuff. So that's the radio guys.
[28:36.070 --> 28:39.950]  The radio guys know a lot about all these electromagnetic things
[28:40.730 --> 28:43.830]  and spycraft there. So a lot of spycraft comes from that.
[28:43.830 --> 28:47.690]  We have people who do side-channel attacks who come from hardware. Hardware people
[28:47.690 --> 28:50.330]  who like to build CPUs and look into
[28:51.570 --> 28:54.230]  meldons, vectors, cache lines. So those guys
[28:54.230 --> 28:57.830]  also do side-channel attacks in a different way. We have cryptographers,
[28:57.830 --> 29:02.290]  people who are from a crypto background like me, who are more into that.
[29:03.050 --> 29:05.970]  So it really depends on your use case. You have people who do web security with
[29:05.970 --> 29:10.590]  side-channel attacks and side-channel attacks means more SQL injection.
[29:10.770 --> 29:14.370]  So I think everyone can touch it by
[29:14.370 --> 29:18.190]  the band. It's fairly easy to get into it. I think
[29:18.190 --> 29:22.190]  there is this apprehension sometimes. The first time I read
[29:22.310 --> 29:25.910]  a paper about it, I probably didn't get the best paper to read as an intro.
[29:25.910 --> 29:30.470]  It felt very bizarre to me. I didn't really understand what they were going for.
[29:30.870 --> 29:32.550]  I was a little bit like... it took me
[29:33.950 --> 29:38.290]  three to four months to get used to the mindset of it.
[29:38.290 --> 29:42.270]  I think it's a very powerful mindset. I think it's a very fun experience to do.
[29:43.190 --> 29:45.730]  If you are interested in side-channel attacks,
[29:45.730 --> 29:49.630]  specifically on hardware, and you want to start without
[29:49.630 --> 29:53.510]  machine learning, like more simple stuff like SSTC code,
[29:53.510 --> 29:57.410]  CheapWhisper, which is a thing that is very affordable
[29:57.410 --> 30:01.730]  and even you don't need the whole thing, you can just run out of existing traces,
[30:01.730 --> 30:05.590]  has a super cool tutorial. I think Corning from CheapWhisper has put
[30:06.630 --> 30:10.030]  a tremendous amount of Jupyter, Python code.
[30:10.030 --> 30:13.830]  You can get to it, you can play with it, understand how it works, and you're going to
[30:13.830 --> 30:17.170]  recover an ASP. And then you'll be super happy.
[30:17.250 --> 30:21.590]  You'll have this super intense satisfaction that you're going to work
[30:21.590 --> 30:24.730]  not necessarily on everything, but it's going to start to make sense.
[30:25.350 --> 30:30.630]  As I said, it's for everyone who is interested in pen testing, one way or another,
[30:30.630 --> 30:31.990]  or have fun.
[30:32.450 --> 30:38.490]  You want to break into a lock. Maybe there's a timing attack.
[30:38.670 --> 30:41.850]  There was some petitions that some of the
[30:42.410 --> 30:45.690]  super high security locks, the Kaban
[30:46.230 --> 30:49.310]  one where you have rotation and things, might have a timing attack.
[30:49.710 --> 30:51.930]  There are secretaries that may be there.
[30:52.470 --> 30:57.130]  For me, it's for everyone.
[30:58.750 --> 31:01.910]  I love that you went to radio first and then math
[31:01.910 --> 31:04.810]  and crypts came later. That's good, right?
[31:05.950 --> 31:09.470]  It's not a deep mathematical background, to be clear.
[31:09.470 --> 31:11.930]  It's literally observing a signal.
[31:12.050 --> 31:16.530]  If I do A, the signal looks like this. If I do B, the signal looks like this.
[31:16.530 --> 31:20.230]  If I can see differences, then I can construct something.
[31:20.410 --> 31:24.450]  Of course, you can do more and more complicated stuff to do more hypotheses.
[31:24.610 --> 31:28.150]  That becomes complicated at some point.
[31:28.570 --> 31:32.190]  The basic stuff is really like, I look at something.
[31:32.190 --> 31:35.590]  It's a very experimental, very hacking thing.
[31:35.590 --> 31:40.770]  It's for doers. For people who like to tinker with stuff.
[31:40.850 --> 31:43.850]  Basically, if you're here, you're on the chat, you are the right person.
[31:43.850 --> 31:47.710]  Let's put it that way. If you are a DevCon person, you are the right audience for the
[31:47.710 --> 31:49.750]  citation attack, because it's all about doing.
[31:51.030 --> 31:56.010]  Math is here to help you and maybe to push it further, but that's not the core of it.
[31:56.010 --> 32:00.050]  The core of it is... matter.
[32:00.110 --> 32:03.190]  Things. The world is made of stuff which
[32:03.190 --> 32:07.450]  does not behave the way people want. It has a secret, hidden property
[32:07.450 --> 32:11.170]  you'd like to uncover. That's what citation attack is. I hope I said it
[32:11.170 --> 32:13.850]  and I get you excited to try it. I hope so.
[32:15.670 --> 32:18.850]  We're at the top of the hour. We appreciate the
[32:19.630 --> 32:21.930]  generosity with your time in answering these questions.
[32:23.070 --> 32:27.530]  Pretty excited to look at the follow-on work coming out of this.
[32:28.110 --> 32:31.690]  Thank you for everything you've done. We'll see you next year, right?
[32:31.690 --> 32:35.310]  Yeah, I hope so. Next year. I hope actually next year
[32:35.310 --> 32:39.530]  is this year's talk. I'm not going to tell you what it is.
[32:39.530 --> 32:43.910]  It's a surprise. As I said, I'll post on Twitter when the GitHub is up.
[32:44.310 --> 32:47.110]  I'm at Eli on Twitter.
[32:47.490 --> 32:50.710]  The slides are online as well.
[32:52.330 --> 32:55.470]  I'll post it on the chat. I can't post a link, right?
[32:55.470 --> 32:56.490]  I'm not going to get that.
[32:57.650 --> 32:59.470]  You can, and I just did.
[32:59.810 --> 33:04.350]  I promise I'll post as early as I can.
[33:05.090 --> 33:08.530]  Thank you so much for watching the talk. Hopefully next year we're all
[33:08.530 --> 33:12.610]  in person. As usual, I'm always happy
[33:12.610 --> 33:16.430]  to answer any questions. Just hit me with a DM or on Discord
[33:16.430 --> 33:19.190]  or whatever you guys want, and I'll try to do my best to answer questions.
[33:19.630 --> 33:21.950]  Thank you so much, Eli. I hope you have a nice DEF CON.
[33:21.950 --> 33:25.670]  There's always a cool talk to watch. I'm super excited to watch
[33:26.050 --> 33:28.390]  a few more. Thank you so much.