Are you seeing us, sir?
Okay, we're good.
Alright guys, we have Ellie Burstyn
here to talk to us today about Hacker's Guide to Side Channels.
And with that, I'd like to turn it over
to you to have any sort of first questions, or first answers.
And we'll start taking questions on the Discord channel.
So, thank you for joining us. And any sort of
open remarks or anything?
Thank you for watching the talk. I would have loved to do it in person.
I kind of miss the DevCon ambience, but I hope we'll try
to have a good chat, ask anything you want, and try to do my best.
And again, thank you so much for watching the talk.
So, I guess I'll start off.
I think you did a good job
in the talk, talking about the sort of why of machine learning, and why
the model predicted... or why
machine learning decided the way it decided,
if that makes sense. And why the model predicted what it predicted
in order to understand how a defender would react to that.
I don't know if you want to elaborate on that talk. I've never sort of...
I've never thought of machine learning...
you think of machine learning, judging it on what the outcome of it is,
not what led to that outcome, and what
defense to build from it. So, I don't know if you want to comment on that
thought, or if it even makes sense, what I just asked.
No, it does. It does. It does.
I think we have a lot of security tools for debugging.
I think if you want to debug a C++ program, we have debugger.
We have Python debugger, C++ debugger.
Most of the things we can debug, because we have a way
to introspect where the bug is triggered.
The systems, the entire stack is developed around
error handling. The problem is how the crypto is.
You run a crypto algorithm on the hardware, and
you have no idea why information is taken.
You have a leak. You know that the machine learning
is finding the correct key, or the correct attack point.
And you're like, OK, I developed this kind of implementation, and we do at Google
have our own cryptographic chip, so that's something we're very concerned about.
And everyone who has a crypto chip is interested in that question of, OK,
you have a leak, but then what? And prior to machine learning,
we didn't have a technique, or we didn't have a tool,
where you can ask, why? Why do you predict what you do?
This is kind of like a crazy thing about the machine learning thing.
It does things which we can't do otherwise. It's not ideal,
because, you know, we all say, well, machine learning is a black box. That's completely true.
But the only thing we have, which is like, OK, can you please tell me
why? The why is a little bit easy,
but it's like, why? And then we thought, OK,
since we moved from site-generator using statistical estimates to machine learning,
and we talked about it last year at DEF CON, it works really well.
Can we go one step further and try to also ask the model why? And then you can do that.
And as I said, it's very, very brittle. You have to be
super, super precise, and we make it work for one implementation.
And, you know, it's a tool, so obviously we're going to show you the best case.
The truth of the matter is, you know, you have to really be super precise,
which is like CPU instruction precise, so it's not super robust just yet,
but you can do that. And I think that's the only tool in the world who can do that.
That's why Scaled is one of its kind. It's the first generation of it.
You know, five years, ten years from now, we'll be laughing at it and be like, OK,
we've got a way to do it, I'm pretty sure. But it was
two crazy years of
brainstorming and trying ideas until we came up with an idea of doing it.
It came out of necessity. It came out from our project team inside Google
of like, OK guys, you make better attacks, which was not the goal,
but the goal of our whole project was to make a better world, like a more secure world.
I didn't have to pitch a choir, and then
we really wanted to make a tool for our engineering team of like, and around the world of like,
OK, here's a tool you can use, here's a tool lab, here's a debugger for hardware crypto.
And it just doesn't exist. So that's where it comes from.
And without machine learning, it doesn't work, but without the relations, it doesn't work, and without the community,
it doesn't work. We use a lot of the technology behind the scenes, like Unicorn.
And we had a pretty good talk today about Unicorn as well. A lot of people are using Unicorn,
which is a CPU emulator, which is very close to the community, so we are
standing on shoulder of giants, which is bringing some of the interesting
twists to it. That's what it is.
Great. So actually, just jumping off what you said,
are people actually using this to
help identify side channels yet, or
have you been approached by anyone? No, not yet.
To be clear,
we had a lot of debate actually internally, because
it's really super out of the press. I would say the initial
complete success was probably one or two weeks old.
We knew it was somewhat working, but we didn't get it to work as
clearly as it should. It took like, I think maybe 24 hours before
I recorded the talk to be clear. But we saw that
DevCon is virtual, we really want to contribute, we really want to be part
of the community. Usually we're not really good at
things ahead of what we do, but this year we saw that we wanted to really show you
the trading engine, what we were working on as a way to
participate and to be part of the community.
So, no, it's not there yet. The research effort is not there yet.
I'm sure the COVID question is going to come, so I'll answer. Yes, the code will be public
next week. I'm still cleaning up the GitHub to tell you how new it is.
But we went for, here is something new and exciting that we work on.
You guys might get a kick out of looking at it and be inspired,
and that's what we go for. So, the talk, sometime I'm bumping into the middle of it.
Sorry about that, too. I tried to record it with the door closed.
In California, it's like 28 degrees in the room when I try to record, so I was
straining a little bit. I apologize also for my English. But, yeah, we really tried to do
like, this is the state mode talk, which is like, we do show you
bleeding edge. Like, it's a true, you know, very old DevCon spirit.
Like, this is new, we're here to transform it. That's what it was. So, no, it's not here.
Absolutely not.
That's great.
So, the example we're using
were mostly around power, if I understood the
presentation right. And, you know, you mentioned other side channels,
you know, heat, emissions, timing, etc.
I mean, do you see these techniques would apply to all those, or
there wasn't anything unique to the instrumentation
you used, right? No, I don't see there's anything
special to it. I never used, I said, I don't
know if anyone ever used heat. I would be super curious if someone knows about
a heat attack, timing attack, which is super, super interesting.
I've never seen one. Like, in crypto, they might exist,
I don't know. But we thought about, yeah,
magnetic, I think, is one of the big deal.
We wanted to do this here, to be clear.
And extend what we do from power to EM as well.
The truth of the matter is, we cannot go to the office, right, doing remote work in our team,
as many of us are doing in the community, and we don't have
access to our equipment, right. The only thing we can really do is power, because that's what is
plugged into our lab. And the only thing we can access remotely to do
is EM. You have to literally have an EM table, and you have to be on top of the chip.
And that is not doable in the near future.
So, we'd love to do EM. I think the next big target
is that. You would do, maybe timing.
Timing might work too, probably. I think there is a few papers coming out this year
from other groups on machine learning and timing attacks for
Parasite, I believe.
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.
So, as I said, machine learning is an easier way to
take over such an attack for hardware in the next 2-3 years
than when it's going to do it. We just happened to be the first few groups
who are doing it. There are other groups in France.
There's a German group as well who is doing some of it. Some vendors
are taking some of the research and putting it into products. I think that's where it's going to go.
But I think most people are on the power train for now.
Maybe a little bit of timing attack is pretty new this year.
I guess the end is the next.
Yeah, I was wondering that too. It's kind of, as you were saying, you built
your model, I guess, using mostly an emulator. How well
does that scale then to other hardware? Is it kind of the research you've
done, it's that one sample? Or do you think that you're going to need to build your machine learning models
for different types of processors or setups, right? Does that make sense?
Yeah, so for the attack side, we know it works.
I mean, I hope it's not a unique paper, but
since last year we've been working. The last three years we have collected a massive
set of data sets that we really hope to publish.
I'm not going to give a date at that point. Last year I said very soon, and it didn't happen this year.
Or the next year we have. But yes, we have that for
multiple data sets, multiple hardware that works. For the emulation side,
the other side, which is not the machine learning side, the dynamic analysis where we need to
be site-precise, we don't even have a normal. And the thing
is, Intel is, for example, out of the question because
they have a predictive pipeline, so we don't even know, like, depending on
how the Intel predictive pipeline will work or the flush pipeline will work,
the number of instructions is completely non-deterministic. Or at least to the point where, in our
poor brain, we're not going to be able to do it just yet. So if your CPU is too complicated,
I don't think we can. Reduce set instructions should work,
I guess, but like I said, we don't even have a device now because
it's like, oh, it's between, I don't know what the range is, 2 to 12 cycles.
So we have to make an estimated guess. So it works
for ARM, mostly embedded stuff, I assume. Smaller
power would work too. But yes, the emulation side of it is
hard because if you're off, you know, if your
machine learning is correct, it finds the attack, then if you're off
for the cycle for the emulation, you end up, I don't know, like, 6, 12, 15,
100 cycles left or right, and then you're on the wrong
line of code, right? The line of code that I said is true for instructions,
so you might have, you know, you might get lucky if you're a little bit slowly, but
that margin becomes terrifyingly hard. And similarly, there is
a back point at the end of the... you can also apply the end
of the implementation, not the first round, but the end. And then, again,
at that point, every error is compounded, right? So the further you
undertrace on the right side of this, the more you're going to
have a chance of mixing it up. So yes, we choose easy
case, which is like very well-defined ARM, which is a very small set of instructions,
well-defined, well-documented, on an easy C
non-vectorized, because that's the easy case.
Harder case would be like more features of engineering. I think
the people in the committee are interested to help us improve the analyzer
or add more targets. It's probably doable, it's just going to be interesting
reversing engineering exercise, right? And that's what people
put at hardware. It's fun to do, it's just, it's going to be quite worse.
It's a really good question.
Yeah, so, I mean, the attacks
themselves are pretty hard, so it goes to show that
the defensive analysis would be just as hard, right?
Yeah, I mean, we know
that hardware, I mean,
we know that stationary attacks are inevitable, right? Almost inevitable.
There are defenses which might exist, like doubling the bus for
power supply, power attack, but that's not going to be implemented
in hardware. It's too expensive or too costly or too big.
So, everything is inevitable to size your attack to an extent.
The question is, how can we make it right? There are
really cool set of work done
mostly by the French ANSI on MASSKS
which is kind of like the way you make it harder. You can also make it slower.
So, the question is, how slow can be hardware
encryption, right? The question is, how many milliseconds can you tolerate?
The reason why I mention that is, if you use security keys, right,
we create security keys, they use NFC. And the problem with NFC,
NFC is super fast and super low power. So, now, in those settings,
making a super resilient implementation is going to be challenging.
So, being said, this is not AES as we show, but even for that
you cannot switch out. If you want APK, also you cannot switch out.
Well, I don't have a lot of time.
I don't have a lot of power. And with more computation to
harden my thing, that becomes kind of impossible. So, there will always be a trade-off, right?
And as long as there is a trade-off, there is a vulnerability.
So, you know, Tyler's channel attack is probably the most powerful
attack you can do against cryptos these days because this is the one where we know
we cannot solve it. So, interesting.
It's an interesting space.
Pretty interesting.
Yeah, and I'll say, I really appreciated your talk, too, how you went through the different steps.
It was very informative and instructive. Like, even just mentioning explainers,
you did a very good job of explaining everything and really showing the real world examples.
You say, though, you say side-channel attacks are really important for encryption.
How did you get into the side-channel attack space? What drew you to that?
Was it the encryption aspect? How did your research end up on side-channel attacks?
Oh, wow.
That's a hard question.
I think what happened is
before, I always did cryptanalysis.
People might or might not remember it, but
a few years back, we announced the first collision on SHA-1.
And we did it all at that time.
And it took us a while.
It took us a while to do it. Breaking SHA-1 in collaboration
with Mark Stevens, the CWI, took three years.
Most people don't realize that sometimes when we do talk, it's like, oh, that's great. That's nice.
It took three years of effort for us, and I think Mark spent almost ten years on it.
So you get out of breaking SHA-1
I mean, putting it in practice, it was broken by one, but like
providing the first collision, and then, as I said, in 2015
we did the first collision. We showed these two PDFs
which are about to send SHA-1, and then the world did break SHA-1, which was our goal.
Interestingly enough, the backstory, the reason why we decided
to do it is not to do a talk, but because we really wanted to
help people realize that they need to move away from it
at the time Microsoft, XCOR, did not deprecate it
and Firefox was lagging, and it had the immediate effect
that both of them immediately deprecated it, so it was like
why would you ever go into this crazy amount of money
and amount of energy to literally compute
all this? And the answer was
because, at that time, we wanted to show
to the world, it was with both Microsoft and XCOR, and we should
treat it seriously. Again, it was important to get this always in the context
of our team, the research team,
we tried to set up an XOR where people come up to this project and try to figure out
if it can help the world. And then we finished that, and we were like, okay
what else? And then, so yeah,
our first research team is almost a hangover
because we had to get professional marketing and we were like, what's next?
A piece of crypto, and then we were like, okay what's next?
And then we started to talk with the project team, and at that time
something called the Titan chip, publicly,
is developed by Google. It's Google's own crypto chip. And the crypto chip
we talked to the hardware engineer, and they told us, well, no.
So this crazy idea, we come up with one
paper from the French agency, which is the French
control agency specializing in crypto. They have this very, very interesting work
on machine learning and crypto, you should check it out. And I was totally
in love with the idea. The internal team was very interested in
having more resources, and then we realized
it's very, very powerful, very interesting. It's played well into what Google do,
which is machine learning at the time, it's here. It plays well
into core and fundamental research that we do.
It plays well with... that's what we decided to go for. Honestly, we got
from our project team, so it was
completely serendipitous, and has been seen in research more like
you know, talking to people, and it's like
something like that. You want to talk, you get inspired by other people, you build on
other people's work or ideas, and we all keep it to push it further.
So I think that's what it was. I think that was this idea
of come from other people, and take credit for it all.
We met a lot of wonderful people from Ledger,
from Chipwister, you know, Colleen, and many Chipwisters
by the way, the scaffolding committee, the institutional community,
we also have a lot of time to help us, give us pointers
early days.
So we're glad that now we're back.
Great, so we have a question from the audience. Apart from approving the emulation,
what do you see as the next step in this field of side-channel detection?
Detection...
That's a great question.
I think there are
...
I think it goes hand-to-hand with
better attack. Again, we can only explain what we can attack.
I think we have a few working streams on
public key, and a few working streams on other algorithms.
I think that will be interesting to do. We're always looking for people
who are willing to work with us, because it's a very, very big...
I won't say difficult, but it's a lot of grind
to create the data, and to do the machine learning, and that sort of thing.
So if people are interested to collaborate, we're always up for it, because
it's a little bit like, figure out what to do, it's hard. Last year,
when I come, I go, it's so hard to do the IAF model. This year, after a year of
refining the machine learning model and our process, we can basically do it in 10 minutes.
So we went from 5 hours to 15 minutes
by getting just mechanically better at it.
I think it's going to be the same for the other algorithms.
So I really view that. I think we're also going to view, I hope,
people being creative for it. I don't know.
I would imagine you can do that timing attack. Some people mentioned
cache line as an idea. I found that quite interesting.
There is a holy grail of Intel HDX.
I mean, Enclave is also using crypto. It is crazy
hard to attack, because it's literally baked into the Intel CPU.
However, no one knows if machine learning can do it or not.
Some people we talked to say yes, it's probably doable. I don't know. I never do it.
We don't have necessarily the time to do it by ourselves. We're happy to
contribute, but that's something which is interesting line of research. I think Enclave is
a big deal. Other algorithms are a big deal. But also
we can think of crazy things. Everything which is timing sounds a bit bad.
I would not be surprised if someone even came up with a crazy idea of how to do it
for Bitcoin wallet transactions, or even
what would be another interesting step. SQL injection.
We have a lot of blind SQL injection. Maybe we can
get more out of the timing. We can make more out of the timing that we think we can.
It's unclear. I mean, most of them should have been fixed,
but yeah, I don't know. That's a lot of room,
a lot of creativity. It depends on people's taste.
I'm not sure.
So you mentioned a paper is coming out. Do you have an estimate on when you're going to be
done with that? I'm not going to jinx it, Matt. I'm not going
to do that. Last year I said it's going to be soon. The draft is still on my
desk. And for the schedule paper, I'm going to be completely
honest. I told you we rushed to do it for DEF CON. We really wanted to show you
Building Edge. Literally the paper is not ready yet. The next step for us is
to put everything on GitHub. I'll post the link on Twitter
hopefully next week.
And then we're going to want people to play with it. We'd rather provide
incomplete stuff to people to play, because last year we did
the reverse. We thought we were going to hold, hold, hold, and get everything at once
and it didn't work out. So this year, we're switching the strategy.
I'm going to release early. Imperfect, but early. And then the paper will come later.
Completely what? But yes, the AES datasets
we promised last year are still there. We just haven't got the chance to
release them. And then the schedule paper, you'll be able to play with the code.
Run the code I showed you. Get the verb I showed you. And then
that will be incomplete, because you'll be like, oh, where are the other attack points?
Not there yet. Where are the other models? Not there yet. They're going to get there
when they can. And I make no promises. Because I can't
I don't know what I can keep or not. So I try to be a little bit more
realistic this year than last year. I want to achieve
good people. I was going to ask the same thing, so it's definitely on folks' minds.
We do have a question from the chat. So, you know, are you aware of
any side-channel attacks that are found in the wild, right, where attackers are
using them? Or is this more of where we're thinking about how to defend against these attacks
before, you know, we see them active?
Oh, side-channel are everywhere. Side-channel are everywhere. They're like the
most prevalent form of attack for hardware.
Let me try to figure out which one I can tell you which are pretty interesting. So again,
it's not singular. To put one company like this company is bad,
because I'm going to use all of them. So I start with one of my
favorite companies, which I really like, Ledger.
Two years ago, they had away someone from a timing attack on
the IoT curve. This was the example I gave at the beginning of the talk.
And they were able to recover all the Ledger treasure
by Bitcoin private key. So that's a pretty big deal.
There was a timing attack on a game console.
I think it was streaming on Twitch. I'm not going to give too much
detail, but many, many game consoles
are protected by crypto.
And there was a timing attack to recover some of those secret keys.
That was earlier generation. I'm not talking
5 or 4 or Xbox One.
I'm talking previous generation, but there was a timing attack
who were used to recover crypto keys.
There was many of them. There was an AES one a very long time ago
used by... I believe
it was Dan Bernstein on remote AES. There was one
on cache line attacks on CPUs.
There are so many of them everywhere. Session attacks are
so powerful. The most powerful form of SQL injection
is binary SQL injection. Sorry, session attack. Binary SQL injection
is when you have a SQL injection, but you can't see the output
when you trigger. You do it one character at a time
and you just look at whether the server responds or not. That's a form of session attack.
They are everywhere. It's a super, super practical attack
and usually people are really annoyed and say it's not a good attack because it's a known technique.
It's not a known technique. It's a known technique. It just happens that it works
super, super efficiently on many, many things.
Yep.
And we have it on
physical stuff like electronic locks and things like that.
Oh, I forgot.
I thought that was the most important one. I'm sorry.
Spectre and Meltdown. Right.
Spectre and Meltdown. There you go. The thing which completely destroys your CPU.
They are a form of session attack. So here you go.
As I said, some of the most powerful concrete attacks
we've seen in the last few years are session attacks because they are so hard to
debug, so hard to pull off, to defend against.
Yeah, I think I read something about those.
They were kind of big, right?
Yeah, I pinned in the chat the
article. There's a weird article who can outline that.
It would be good to just read up if you guys are interested.
I think it's QA. There you go. Thank you.
Yep. Yeah, so we've got a couple minutes
left. If we have any more questions, let's get them in here.
Otherwise, we're going to thank
Ellie and
let you guys get back to the con.
One last one for me. Oh, wait, we actually do have one more.
Yeah, so someone who is mainly focused in InfoSec.
What kind of background do you think people kind of lend themselves to
going towards looking at side-channel attacks and thinking about the research you're doing
with being able to detect that in different ways?
What kind of background?
It varies.
We have some people who come from
radio.
For those who don't know, the first initial side-channel attack was actually
in the 1940s or something like that, where they had a typewriter
and the guy was having an oscilloscope, and then he sort of blinked on the oscilloscope
and realized that there was something. And then the Russians put a
user to spy onto people
by looking at vibrations. So that's super old stuff. So that's the radio guys.
The radio guys know a lot about all these electromagnetic things
and spycraft there. So a lot of spycraft comes from that.
We have people who do side-channel attacks who come from hardware. Hardware people
who like to build CPUs and look into
meldons, vectors, cache lines. So those guys
also do side-channel attacks in a different way. We have cryptographers,
people who are from a crypto background like me, who are more into that.
So it really depends on your use case. You have people who do web security with
side-channel attacks and side-channel attacks means more SQL injection.
So I think everyone can touch it by
the band. It's fairly easy to get into it. I think
there is this apprehension sometimes. The first time I read
a paper about it, I probably didn't get the best paper to read as an intro.
It felt very bizarre to me. I didn't really understand what they were going for.
I was a little bit like... it took me
three to four months to get used to the mindset of it.
I think it's a very powerful mindset. I think it's a very fun experience to do.
If you are interested in side-channel attacks,
specifically on hardware, and you want to start without
machine learning, like more simple stuff like SSTC code,
CheapWhisper, which is a thing that is very affordable
and even you don't need the whole thing, you can just run out of existing traces,
has a super cool tutorial. I think Corning from CheapWhisper has put
a tremendous amount of Jupyter, Python code.
You can get to it, you can play with it, understand how it works, and you're going to
recover an ASP. And then you'll be super happy.
You'll have this super intense satisfaction that you're going to work
not necessarily on everything, but it's going to start to make sense.
As I said, it's for everyone who is interested in pen testing, one way or another,
or have fun.
You want to break into a lock. Maybe there's a timing attack.
There was some petitions that some of the
super high security locks, the Kaban
one where you have rotation and things, might have a timing attack.
There are secretaries that may be there.
For me, it's for everyone.
I love that you went to radio first and then math
and crypts came later. That's good, right?
It's not a deep mathematical background, to be clear.
It's literally observing a signal.
If I do A, the signal looks like this. If I do B, the signal looks like this.
If I can see differences, then I can construct something.
Of course, you can do more and more complicated stuff to do more hypotheses.
That becomes complicated at some point.
The basic stuff is really like, I look at something.
It's a very experimental, very hacking thing.
It's for doers. For people who like to tinker with stuff.
Basically, if you're here, you're on the chat, you are the right person.
Let's put it that way. If you are a DevCon person, you are the right audience for the
citation attack, because it's all about doing.
Math is here to help you and maybe to push it further, but that's not the core of it.
The core of it is... matter.
Things. The world is made of stuff which
does not behave the way people want. It has a secret, hidden property
you'd like to uncover. That's what citation attack is. I hope I said it
and I get you excited to try it. I hope so.
We're at the top of the hour. We appreciate the
generosity with your time in answering these questions.
Pretty excited to look at the follow-on work coming out of this.
Thank you for everything you've done. We'll see you next year, right?
Yeah, I hope so. Next year. I hope actually next year
is this year's talk. I'm not going to tell you what it is.
It's a surprise. As I said, I'll post on Twitter when the GitHub is up.
I'm at Eli on Twitter.
The slides are online as well.
I'll post it on the chat. I can't post a link, right?
I'm not going to get that.
You can, and I just did.
I promise I'll post as early as I can.
Thank you so much for watching the talk. Hopefully next year we're all
in person. As usual, I'm always happy
to answer any questions. Just hit me with a DM or on Discord
or whatever you guys want, and I'll try to do my best to answer questions.
Thank you so much, Eli. I hope you have a nice DEF CON.
There's always a cool talk to watch. I'm super excited to watch
a few more. Thank you so much.