WEBVTT
00:00:20.400 --> 00:00:21.600
36C3 preroll music
00:00:21.600 --> 00:00:24.840
Herald Angel: OK. Welcome to our next
talk. It's called flipping bits from
00:00:24.840 --> 00:00:30.090
software without Row hammer, small
reminder Row hammer used, still is a
00:00:30.090 --> 00:00:34.020
software based fault attack. It was
published in 2015. There were
00:00:34.020 --> 00:00:39.660
countermeasures developed and we are still
in the process of deploying these
00:00:39.660 --> 00:00:45.690
everywhere. And now our two speakers are
going to talk about a new software based
00:00:45.690 --> 00:00:56.250
fault attack to execute commands inside
the SGX environment. Our speakers,
00:00:56.250 --> 00:01:05.000
Professor Daniel Gruss from the University
of Graz and Kit Murdoch researching at the
00:01:05.000 --> 00:01:10.750
University of Birmingham. The content of
this talk is actually in her first
00:01:10.750 --> 00:01:17.030
published paper published at IEEE, no
accepted at IEEE Security and Privacy next
00:01:17.030 --> 00:01:21.210
year. In case you do not come from the
academic world, if this is your this is
00:01:21.210 --> 00:01:22.980
always a big deal. If this is your first
paper, it even more is, please welcome
00:01:22.980 --> 00:01:28.000
them, both of you get a round of applause
and enjoy the talk.
00:01:28.000 --> 00:01:31.190
Applause
00:01:31.190 --> 00:01:38.030
Kit Murdoch: Thank you. Hello. Let's get
started. This is my favorite recent
00:01:38.030 --> 00:01:45.270
attack. It's called Clockscrew. And the
reason that it's my favorite is it created
00:01:45.270 --> 00:01:50.140
a new class of fault attacks. Daniel
Gruss: Fault attacks. I, I know that.
00:01:50.140 --> 00:01:53.670
Fault attacks, you take these
oscilloscopes and check the voltage line
00:01:53.670 --> 00:01:58.340
and then you drop the voltage for a f....
Kit: No, you see, this is why this one is
00:01:58.340 --> 00:02:04.810
cool because you don't need any equipment
at all. Adrian Tang. He created this
00:02:04.810 --> 00:02:09.700
wonderful attack that uses DVFS. What is
that?
00:02:09.700 --> 00:02:13.400
Daniel: DVFS ? I don't know, don't
violate format specifications.
00:02:13.400 --> 00:02:19.230
Kit: I asked my boyfriend this morning
what he thought DVFS stood for and he said
00:02:19.230 --> 00:02:22.230
Darth Vader fights Skywalker.
Laughter
00:02:22.230 --> 00:02:26.290
Kit: I'm also wearing his t-shirt
specially for him as well.
00:02:26.290 --> 00:02:30.340
Daniel: Maybe, maybe this is more
technical, maybe dazzling volt for
00:02:30.340 --> 00:02:34.590
security like SGX.
Kit: No, it's not that either. Mine was,
00:02:34.590 --> 00:02:39.650
the one I came up this morning was: Drink
vodka feel silly.
00:02:39.650 --> 00:02:42.930
Laughter
Kit: It's not that either. It stands for
00:02:42.930 --> 00:02:48.590
dynamic voltage and frequency scaling. And
what that means really simply is changing
00:02:48.590 --> 00:02:53.081
the voltage and changing the frequency of
your CPU. Why do you want to do this? Why
00:02:53.081 --> 00:02:58.269
would anyone want to do this? Well, gamers
want fast computers. I am sure there are a
00:02:58.269 --> 00:03:02.860
few people out here who will want a really
fast computer. Cloud Servers want high
00:03:02.860 --> 00:03:07.750
assurance and low running costs. And what
do you do if your hardware gets hot?
00:03:07.750 --> 00:03:13.040
You're going to need to modify them. And
actually finding a voltage and frequency
00:03:13.040 --> 00:03:17.810
that work together is pretty difficult.
And so what the manufacturers have done to
00:03:17.810 --> 00:03:23.230
make this easier, is they've created a way
to do this from software. They created
00:03:23.230 --> 00:03:29.409
memory mapped registers. You modify this
from software and it has an impact on the
00:03:29.409 --> 00:03:35.069
hardware. And that's what this wonderful
clockscrew attack did. But they found
00:03:35.069 --> 00:03:41.939
something else out, which is you may have
heard of: trust zone. Trust zone is in an
00:03:41.939 --> 00:03:47.850
enclave in ARM chips that should be able
to protect your data. But if you can
00:03:47.850 --> 00:03:52.360
modify the frequency and voltage of the
whole core, then you can modify it for
00:03:52.360 --> 00:03:59.219
both trust zone and normal code. And this
is their attack. In software they modified
00:03:59.219 --> 00:04:05.290
the frequency to make it outside of the
normal operating range. And they induced
00:04:05.290 --> 00:04:12.459
faults. And so in an arm chip running on a
mobile phone, they managed to get out an
00:04:12.459 --> 00:04:17.511
AES key from within trust zone. They
should not be able to do that. They were
00:04:17.511 --> 00:04:22.710
able to trick trust zone into loading a
self-signed app. You should not be able to
00:04:22.710 --> 00:04:31.900
do that. That made this ARM attack really
interesting. This year another attack came
00:04:31.900 --> 00:04:39.879
out called volt jockey. This also attacked
ARM chips. But instead of looking at
00:04:39.879 --> 00:04:49.460
frequency on ARM chips, they were looking
at voltage on ARM chips. We're thinking,
00:04:49.460 --> 00:04:57.270
what about Intel?
Daniel: OK, so Intel. Actually, I know
00:04:57.270 --> 00:05:02.060
something about Intel because I had this
nice laptop from HP. I really liked it,
00:05:02.060 --> 00:05:06.520
but it had this problem that it was going
too hot all the time and I couldn't even
00:05:06.520 --> 00:05:12.909
work without it shutting down all the time
because of the heat problem. So what I did
00:05:12.909 --> 00:05:17.639
was I undervolted the CPU and actually
this worked for me for several years. I
00:05:17.639 --> 00:05:21.530
used this undervolted for several years.
You can also see this, I just took this
00:05:21.530 --> 00:05:27.020
from somewhere on the Internet and they
compared with undervolting and without
00:05:27.020 --> 00:05:31.930
undervolting. And you can see that the
benchmark score improves by undervolting
00:05:31.930 --> 00:05:38.879
because you don't run into the thermal
throttling that often. So there are
00:05:38.879 --> 00:05:43.840
different tools to do that. On Windows you
could use RMClock, there's also
00:05:43.840 --> 00:05:47.789
Throttlestop. On Linux there's the Linux-
intel-undervolt GitHub repository.
00:05:47.789 --> 00:05:52.960
Kit: And there's one more, actually.
Adrian Tang, who I don't know if you know
00:05:52.960 --> 00:05:58.889
a bit of a fan. He was the lead author on
Clocks Screw. He wrote his PhD Thesis and
00:05:58.889 --> 00:06:03.210
in the appendix he talked about
undervolting on Intel machines and how you
00:06:03.210 --> 00:06:07.550
do it. And I wish I'd read that before I
started the paper. That would have saved
00:06:07.550 --> 00:06:12.409
an awful lot of time. But thank you to the
people on the Internet for making my life
00:06:12.409 --> 00:06:17.980
a lot easier, because what we discovered
was there is this magic module specific
00:06:17.980 --> 00:06:26.880
register and it's called Hex 150. And this
enables you to change the voltage the
00:06:26.880 --> 00:06:31.229
people on the Internet did the work for
me. So I know how it works. You first of
00:06:31.229 --> 00:06:37.039
all tell it the plain RDX, what it is you
want to, raise the voltage or lower the
00:06:37.039 --> 00:06:43.099
voltage. We discovered that the core and
the cache are on the same plane. So you
00:06:43.099 --> 00:06:46.509
have to modify them both. But it has no
effect, they're together. I guess in the
00:06:46.509 --> 00:06:50.750
future they'll be separate. Then you
modify the offset to say, I want to raise
00:06:50.750 --> 00:06:57.080
it by this much or lower it by this much.
So I thought, let's have a go. Let's write
00:06:57.080 --> 00:07:05.599
a little bit of code. Here is the code.
The smart people amongst you may have
00:07:05.599 --> 00:07:15.539
noticed something. I suspect even my
appalling C, even I would recognize that
00:07:15.539 --> 00:07:20.810
that loop should never exit. I'm just
multiplying the same thing again and again
00:07:20.810 --> 00:07:25.499
and again and again and again and
expecting it to exit. That shouldn't
00:07:25.499 --> 00:07:32.439
happen. But let's look at what happened.
So I'm gonna show you what I did. Oh..
00:07:32.439 --> 00:07:41.620
There we go. So the first thing I'm gonna
do is I'm going to set the frequency to be
00:07:41.620 --> 00:07:45.749
one thing because I'm gonna play with
voltage and if I'm gonna play with
00:07:45.749 --> 00:07:51.210
voltage, I want the frequency to be
set. So, It's quite easy using cpupower,
00:07:51.210 --> 00:07:56.530
you set the maximum and the minimum to be
1 gigahertz. And now my machine is running
00:07:56.530 --> 00:08:01.169
at exactly 1 gigahertz. Now we'll look at
the bit of code that you need to
00:08:01.169 --> 00:08:05.091
undervolt, again I didn't do the work,
thank you to the people on the internet
00:08:05.091 --> 00:08:12.199
for doing this. You put the MSR into the
kernel and let's have a look at the code.
00:08:12.199 --> 00:08:21.030
Does that look right? Oh, it does, looks
much better up there. Yes, it's that one
00:08:21.030 --> 00:08:27.061
line of code. That is the one line of code
you need to open and then we're going to
00:08:27.061 --> 00:08:33.140
write to it. And again, oh why is it doing
that? We have a touch sensitive screen
00:08:33.140 --> 00:08:52.670
here. Might touch it again. That's the
line of code that's gonna open it and
00:08:52.670 --> 00:08:55.970
that's how you write to it. And again, the
people on the Internet did the work for me
00:08:55.970 --> 00:08:59.030
and told me how I had to write that. So
what I can do here is I'm just going to
00:08:59.030 --> 00:09:04.250
undervolt and I'm gonna undervolt,
multiplying deadbeef by this really big
00:09:04.250 --> 00:09:08.660
number. I'm starting at minus two hundred
and fifty two millivolts. And we're just
00:09:08.660 --> 00:09:11.140
going to see if I ever get out of this
loop.
00:09:11.140 --> 00:09:14.020
Daniel: But surely the system would just
crash, right?
00:09:14.020 --> 00:09:21.880
Kit: You'd hope so, wouldn't you? Let's
see, there we go! We got a fault. I was a
00:09:21.880 --> 00:09:25.070
bit gobsmacked when that happened because
the system didn't crash.
00:09:25.070 --> 00:09:29.790
Daniel: So that doesn't look too good. So
the question now is, what is the... So you
00:09:29.790 --> 00:09:33.050
show some voltage here, some undervolting.
Kit: Yeah
00:09:33.050 --> 00:09:36.690
Daniel: What undervolting is actually
required to get a bit flip?
00:09:36.690 --> 00:09:40.760
Kit: We did a lot of tests. We didn't just
multiply by deadbeef. We also multiplied
00:09:40.760 --> 00:09:44.860
by random numbers. So here I'm going to
just generate two random numbers. One is
00:09:44.860 --> 00:09:50.210
going up to f f f f f f one is going up to
ff. I'm just going to try different, again
00:09:50.210 --> 00:09:57.450
I'm going to try undervolting to see if I
get different bit flips. And again, I got
00:09:57.450 --> 00:10:03.620
the same bit flipped, so I'm getting the
same one single bit flip there. Okay, so
00:10:03.620 --> 00:10:08.000
maybe it's only ever going to be one bit
flip. Ah, I got a different bit flip and
00:10:08.000 --> 00:10:12.210
again a different bit flip and it's,
you'll notice they always appear to be
00:10:12.210 --> 00:10:17.060
bits together next to one another. So to
answer Daniel's question, I pressed my
00:10:17.060 --> 00:10:22.980
machine a lot in the process of doing
this, but I wanted to know what were good
00:10:22.980 --> 00:10:29.330
values to undervolt at. And here they are.
We tried for all the frequencies. We tried
00:10:29.330 --> 00:10:33.290
what was the base voltage? And then when
was the point at which we got the first
00:10:33.290 --> 00:10:37.530
fault? And once we'd done that, it made
everything really easy. We just made sure
00:10:37.530 --> 00:10:41.430
we didn't go under that and ended up with
a kernel panic or the machine crashing.
00:10:41.430 --> 00:10:47.160
Daniel: So this is already great. I think
this looks like it is exploitable and the
00:10:47.160 --> 00:10:53.910
first thing that you need when you are
working on a vulnerability is the name and
00:10:53.910 --> 00:11:00.821
the logo and maybe a Website. Everything
like that. And real people on the Internet
00:11:00.821 --> 00:11:05.690
agree with me. Like this tweet.
Laughter
00:11:05.690 --> 00:11:12.160
Daniel: Yes. So we need a name and a logo.
Kit: No, no, we don't need it. Come on.
00:11:12.160 --> 00:11:15.121
then. Go on then. What is your idea?
Daniel: So I thought this is like, it's
00:11:15.121 --> 00:11:20.920
like Row hammer. We are flipping bits, but
with voltage. So I called it Volt hammer
00:11:20.920 --> 00:11:25.370
and I already have a logo for it.
Kit: We're not, we're not giving it a
00:11:25.370 --> 00:11:27.580
logo.
Daniel: No, I think we need a logo because
00:11:27.580 --> 00:11:34.880
people can relate more to the images
there, to the logo that we have. Reading a
00:11:34.880 --> 00:11:39.140
word is much more complicated than seeing
a logo somewhere. It's better for
00:11:39.140 --> 00:11:45.480
communication. You make it easier to talk
about your vulnerability. Yeah? And the
00:11:45.480 --> 00:11:50.070
name, same thing. How, how would you like
to call it? Like undervolting on Intel to
00:11:50.070 --> 00:11:54.350
induce flips in multiplications to then
run an exploit? No, that's not a good
00:11:54.350 --> 00:12:02.250
vulnerability name. And speaking of the
name, if we choose a fancy name, we might
00:12:02.250 --> 00:12:05.550
even make it into TV shows like Row
hammer.
00:12:05.550 --> 00:12:11.740
Video Clip 1A: The hacker used a DRAM Row
hammer exploit to gain kernel privileges.
00:12:11.740 --> 00:12:15.050
Video Clip 1B: HQ, yeah we've got
something.
00:12:15.050 --> 00:12:20.690
Daniel: So this was in designated Survivor
in March 2018 and this guy just got shot.
00:12:20.690 --> 00:12:25.601
So hopefully we won't get shot but
actually we have also been working. So my
00:12:25.601 --> 00:12:32.830
group has been working on Row hammer and
presented this in 2015 here at CCC, in
00:12:32.830 --> 00:12:37.500
Hamburg back then. It was Row hammer JS
and we called it root privileges for web
00:12:37.500 --> 00:12:40.661
apps because we showed that you can do
this from JavaScript in a browser. Looks
00:12:40.661 --> 00:12:44.170
pretty much like this, we hammered the
memory a bit and then we see a bit flips
00:12:44.170 --> 00:12:49.690
in the memory. So how does this work?
Because maybe for another fault attack,
00:12:49.690 --> 00:12:52.800
software based fault attack, the only
other software based fault attack that we
00:12:52.800 --> 00:12:59.370
know. So, these are related to DFS and
this is a different effect. So what do we
00:12:59.370 --> 00:13:03.870
do here is we look at the DRAM and the
DRAM is organized in multiple rows and we
00:13:03.870 --> 00:13:10.050
will access these rows. These rows consist
of so-called cells, which are capacitors
00:13:10.050 --> 00:13:14.450
and transistors each. And they store one
bit of information each. And the row
00:13:14.450 --> 00:13:18.320
buffer, the row size usually is something
like eight kilobytes. And then when you
00:13:18.320 --> 00:13:21.970
read something, you copy it to the row
buffer. So it works pretty much like this:
00:13:21.970 --> 00:13:25.820
You read from a row, you copy it to the
row buffer. The problem now is, these
00:13:25.820 --> 00:13:31.000
capacitors leak over time so you need to
refresh them frequently. And they have
00:13:31.000 --> 00:13:37.660
also a maximum refresh interval defined in
a standard to guarantee data integrity.
00:13:37.660 --> 00:13:43.150
Now the problem is that cells leak fast
upon proximate accesses, and that means if
00:13:43.150 --> 00:13:49.450
you access two locations in proximity to a
third location, then the third location
00:13:49.450 --> 00:13:54.110
might flip a bit without accessing it. And
this has been exploited in different
00:13:54.110 --> 00:13:58.710
exploits. So the usual strategies is
maybe, maybe we can use some of them. So
00:13:58.710 --> 00:14:03.370
the usual strategies here are searching
for a page with a bit flip. So you search
00:14:03.370 --> 00:14:08.230
for it and then you find some. Ah, There
is a flip here. Then you release the page
00:14:08.230 --> 00:14:13.180
with the flip in the next step. Now this
memory is free and now you allocate a lot
00:14:13.180 --> 00:14:17.710
of target pages, for instance, page
tables, and then you hope that the target
00:14:17.710 --> 00:14:22.460
page is placed there. If it's a page
table, for instance, like this and you
00:14:22.460 --> 00:14:26.650
induce a bit flip. So before it was
pointing to User page, then it was
00:14:26.650 --> 00:14:32.540
pointing to no page at all because we
maybe unmapped it. And the page that we
00:14:32.540 --> 00:14:37.850
use the bit flip now is actually the one
storing all of the PTEs here. So the one
00:14:37.850 --> 00:14:42.990
in the middle is stored down there. And
this one now has a bit flip and then our
00:14:42.990 --> 00:14:49.650
pointer to our own user page changes due
to the big flip and points to hopefully
00:14:49.650 --> 00:14:54.990
another page table because we filled that
memory with page tables. Another direction
00:14:54.990 --> 00:15:01.840
that we could go here is flipping bits in
code. For instance, if you think about a
00:15:01.840 --> 00:15:07.370
password comparison, you might have a jump
equal check here and the jump equal check
00:15:07.370 --> 00:15:13.190
if you flip one bit, it transforms into a
different instruction. And fortunately, oh
00:15:13.190 --> 00:15:18.290
this already looks interesting. Ah,
Perfect. Changing the password check nto a
00:15:18.290 --> 00:15:25.670
password incorrect check. I will always be
root. And yeah, that's basically it. So
00:15:25.670 --> 00:15:30.700
these are two directions that we might
look at for Row hammer. That's also maybe
00:15:30.700 --> 00:15:35.030
a question for Row hammer, why would we
even care about other fault attacks?
00:15:35.030 --> 00:15:39.820
Because Row hammer works on DDR 3, it
works on DDR 4, it works on ECC memory.
00:15:39.820 --> 00:15:47.840
Kit: Does it, how does it deal with SGX?
Daniel: Ahh yeah, yeah SGX. Ehh, yes. So
00:15:47.840 --> 00:15:51.420
maybe we should first explain what SGX is.
Kit: Yeah, go for it.
00:15:51.420 --> 00:15:56.530
Daniel: SGX is a so-called TEE trusted
execution environment on Intel processors
00:15:56.530 --> 00:16:01.660
and Intel designed it this way that you
have an untrusted part and this runs on
00:16:01.660 --> 00:16:05.880
top of an operating system, inside an
application. And inside the application
00:16:05.880 --> 00:16:10.660
you can now create an enclave and the
enclave runs in a trusted part, which is
00:16:10.660 --> 00:16:16.790
supported by the hardware. The hardware is
the trust anchor for this trusted enclave
00:16:16.790 --> 00:16:20.040
and the enclave, now you can from the
untrusted part, you can call into the
00:16:20.040 --> 00:16:24.910
enclave via a Callgate pretty much like a
system call. And in there you execute a
00:16:24.910 --> 00:16:31.670
trusted function. Then you return to this
untrusted part and then you can continue
00:16:31.670 --> 00:16:35.330
doing other stuff. And the operating
system has no direct access to this
00:16:35.330 --> 00:16:40.020
trusted part. This is also protected
against all kinds of other attacks. For
00:16:40.020 --> 00:16:44.290
instance, physical attacks. If you look at
the memory that it uses, maybe I have 16
00:16:44.290 --> 00:16:50.100
gigabytes of RAM. Then there is a small
region for the EPC, the enclave page
00:16:50.100 --> 00:16:55.040
cache, the memory that enclaves use and
it's encrypted and integrity protected and
00:16:55.040 --> 00:16:59.500
I can't tamper with it. So for instance,
if I want to mount a cold boot attack,
00:16:59.500 --> 00:17:04.350
pull out the DRAM, put it in another
machine and read out what content it has.
00:17:04.350 --> 00:17:07.970
I can't do that because it's encrypted.
And I don't have the key. The key is in
00:17:07.970 --> 00:17:14.939
the processor quite bad. So, what happens
if we have bit flips in the EPC? Good
00:17:14.939 --> 00:17:21.839
question. We tried that. The integrity
check fails. It locks up the memory
00:17:21.839 --> 00:17:27.280
controller, which means no further memory
accesses whatsoever run through this
00:17:27.280 --> 00:17:33.990
system. Everything stays where it is and
the system halts basically. It's no
00:17:33.990 --> 00:17:41.420
exploit, it's just denial of service.
Kit: Huh. So maybe SGX can save us. So
00:17:41.420 --> 00:17:47.360
what I want to know is, Row Hammer clearly
failed because of the integrity check. Is
00:17:47.360 --> 00:17:51.830
my attack where I can flip bits. Is this
gonna work inside SGX?
00:17:51.830 --> 00:17:55.040
Daniel: I don't think so because they
have integrity protection, right?
00:17:55.040 --> 00:17:59.540
Kit: So what I'm gonna do is run the same
thing in the right hand side is user
00:17:59.540 --> 00:18:03.750
space. In the left hand side is the
enclave. As you can see, I'm running at
00:18:03.750 --> 00:18:12.280
minus 261 millivolts. No error minus 262.
No error minus 2... fingers crossed we
00:18:12.280 --> 00:18:20.920
don't get a kernel panic. Do you see that
thing at the bottom? That's a bit flip
00:18:20.920 --> 00:18:24.760
inside the enclave. Oh, yeah.
Daniel: That's bad.
00:18:24.760 --> 00:18:29.910
Applause
Kit: Thank you. Yeah and it's the same
00:18:29.910 --> 00:18:33.920
bit flip that I was getting in user space
, that is also really interesting.
00:18:33.920 --> 00:18:38.251
Daniel: I have an idea. So, it's
surprising that it works right. But I have
00:18:38.251 --> 00:18:45.080
an idea. This is basically doing the same
thing as clocks group. But on SGX, right?
00:18:45.080 --> 00:18:47.320
Kit: Yeah.
Daniel: And I thought maybe you didn't
00:18:47.320 --> 00:18:51.570
like the previous logo, maybe it was just
too much. So I came up with something more
00:18:51.570 --> 00:18:52.800
simple...
Kit: You've come up with a new... He's
00:18:52.800 --> 00:18:55.790
come up with a new name.
Daniel: Yes, SGX Screw. How do you like
00:18:55.790 --> 00:18:59.001
it?
Kit: No, we don't even have an attack. We
00:18:59.001 --> 00:19:02.150
can't have a logo before we have an
attack.
00:19:02.150 --> 00:19:07.350
Daniel: The logo is important, right? I
mean, how would you present this on a
00:19:07.350 --> 00:19:08.670
website
without a logo?
00:19:08.670 --> 00:19:11.770
Kit: Well, first of all, I need an attack.
What am I going to attack with this?
00:19:11.770 --> 00:19:15.060
Daniel: I have an idea what we could
attack. So, for instance, we could attack
00:19:15.060 --> 00:19:22.300
crypto, RSA. RSA is a crypto algorithm.
It's a public key crypto algorithm. And
00:19:22.300 --> 00:19:28.280
you can encrypt or sign messages. You can
send this over an untrusted channel. And
00:19:28.280 --> 00:19:35.560
then you can also verify. So this is
actually a typo which should be decrypt...
00:19:35.560 --> 00:19:43.230
there, encrypt verifying messages with a
public key or decrypt sign messages with a
00:19:43.230 --> 00:19:53.590
private key. So how does this work? Yeah,
basically it's based on exponention modulo a
00:19:53.590 --> 00:20:01.270
number and this number is computed from
two prime numbers. So you, for the
00:20:01.270 --> 00:20:09.360
signature part, which is similar to the
decryption basically, you take the hash of
00:20:09.360 --> 00:20:17.760
the message and then take it to the power
of d modulo n, the public modulus, and
00:20:17.760 --> 00:20:26.390
then you have the signature and everyone
can verify that this is actually, later on
00:20:26.390 --> 00:20:34.430
can verify this because the exponent part
is public. So n is also public so we can
00:20:34.430 --> 00:20:39.880
later on do this. Now there is one
optimization which is quite nice, which is
00:20:39.880 --> 00:20:44.541
Chinese remainder theorem. And this part
is really expensive. It takes a long time.
00:20:44.541 --> 00:20:51.000
So it's a lot faster, if you split this in
multiple parts. For instance, if you split
00:20:51.000 --> 00:20:56.320
it in two parts, you do two of those
exponentations, but with different
00:20:56.320 --> 00:21:02.100
numbers, with smaller numbers and then it's
cheaper. It takes fewer rounds. And if you
00:21:02.100 --> 00:21:06.880
do that, you of course have to adapt the
formula up here to compute the signature
00:21:06.880 --> 00:21:12.510
because, you now put it together out of
the two pieces of the signature that you
00:21:12.510 --> 00:21:19.390
compute. OK, so this looks quite
complicated, but the point is we want to
00:21:19.390 --> 00:21:26.690
mount a fault attack on this. So what
happens if we fault this? Let's assume we
00:21:26.690 --> 00:21:36.130
have two signatures which are not
identical. Right, S and S', and we
00:21:36.130 --> 00:21:41.120
basically only need to know that in one of
them, a fault occurred. So the first is
00:21:41.120 --> 00:21:45.140
something, the other is something else. We
don't care. But what you see here is that
00:21:45.140 --> 00:21:51.510
both are multiplied by Q plus s2. And if
you subtract one from the other, what do
00:21:51.510 --> 00:21:56.970
you get? You get something multiplied with
Q. There is something else that is
00:21:56.970 --> 00:22:03.480
multiplied with Q, which is P and n is
public. So what we can do now is we can
00:22:03.480 --> 00:22:09.640
compute the greatest common divisor of
this and n and get q.
00:22:09.640 --> 00:22:14.730
Kit: Okay. So I'm interested to see if...
I didn't understand a word of that, but
00:22:14.730 --> 00:22:19.890
I'm interested to see if I can use this to
mount an attack. So how am I going to do
00:22:19.890 --> 00:22:25.690
this? Well, I'll write a little RSA
decrypt program and what I'll do is I use
00:22:25.690 --> 00:22:32.330
the same bit of multiplication that I've
been using before. And when I get a bit
00:22:32.330 --> 00:22:39.280
flip, then I'll do the decryption. All
this is happening inside SGX, inside the
00:22:39.280 --> 00:22:44.141
enclave. So let's have a look at this.
First of all, I'll show you the code that
00:22:44.141 --> 00:22:51.580
I wrote, again copied from the Internet.
Thank you. So there it is, I'm going to
00:22:51.580 --> 00:22:56.380
trigger the fault.I'm going to wait for
the triggered fault, then I'm going to do
00:22:56.380 --> 00:23:00.870
a decryption. Well, let's have a quick
look at the code, which should be exactly
00:23:00.870 --> 00:23:04.970
the same as it was right at the very
beginning when we started this. Yeah.
00:23:04.970 --> 00:23:10.240
There's my deadbeef written slightly
differently. But there is my deadbeef. So,
00:23:10.240 --> 00:23:13.730
now this is ever so slightly messy on the
screen, but I hope you're going to see
00:23:13.730 --> 00:23:22.850
this. So minus 239. Fine. Still fine.
Still fine. I'll just pause there. You can
00:23:22.850 --> 00:23:27.360
see at the bottom I've written meh - all
fine., If you're wondering. So what we're
00:23:27.360 --> 00:23:33.059
looking at here is a correct decryption
and you can see inside the enclave, I'm
00:23:33.059 --> 00:23:38.340
initializing p and I'm initializing q. And
those are part of the private key. I
00:23:38.340 --> 00:23:43.960
shouldn't be able to get those. So 239
isn't really working. Let's try going up
00:23:43.960 --> 00:23:49.309
to minus 240. Oh oh oh oh! RSA error, RSA
error. Exciting!
00:23:49.309 --> 00:23:51.680
Daniel: Okay, So this should work for the
attack then.
00:23:51.680 --> 00:23:57.370
Kit: So let's have a look, again. I copied
somebodys attack on the Internet where
00:23:57.370 --> 00:24:04.210
they very kindly, It's called the lenstra
attack. And again, I got I got an output.
00:24:04.210 --> 00:24:08.150
I don't know what it is because I didn't
understand any of that crypto stuff.
00:24:08.150 --> 00:24:09.620
Daniel: Me neither.
Kit: But let me have a look at the source
00:24:09.620 --> 00:24:15.690
code and see if that exists anywhere in
the source code inside the enclave. It
00:24:15.690 --> 00:24:22.180
does. I found p. And if I found p, I can
find q. So just to summarise what I've
00:24:22.180 --> 00:24:31.830
done, from a bit flip I have got the
private key out of the SGX enclave and I
00:24:31.830 --> 00:24:36.130
shouldn't be able to do that.
Daniel: Yes, yes and I think I have an
00:24:36.130 --> 00:24:39.760
idea. So you didn't like the previous...
Kit: Ohh, I know where this is going. Yes.
00:24:39.760 --> 00:24:45.980
Daniel: ...didn't like the previous name.
So I came up with something more cute and
00:24:45.980 --> 00:24:52.740
relatable, maybe. So I thought, this is an
attack on RSA. So I called it Mufarsa.
00:24:52.740 --> 00:24:57.520
Laughter
Daniel: My Undervolting Fault Attack On
00:24:57.520 --> 00:24:59.700
RSA.
Kit: That's not even a logo. That's just a
00:24:59.700 --> 00:25:02.260
picture of a lion.
Daniel: Yeah, yeah it's, it's sort of...
00:25:02.260 --> 00:25:04.660
Kit: Disney are not going to let us use
that.
00:25:04.660 --> 00:25:07.429
Laughter
Kit: Well it's not, is it Star Wars? No,
00:25:07.429 --> 00:25:10.690
I don't know. OK. OK, so Daniel, I really
enjoyed it.
00:25:10.690 --> 00:25:13.670
Daniel: I don't think you will like any of
the names I suggest.
00:25:13.670 --> 00:25:17.940
Kit: Probably not. But I really enjoyed
breaking RSA. So what I want to know is
00:25:17.940 --> 00:25:19.110
what else can I break?
Daniel: Well...
00:25:19.110 --> 00:25:22.750
Kit: Give me something else I can break.
Daniel: If you don't like the RSA part, we
00:25:22.750 --> 00:25:28.300
can also take other crypto. I mean there
is AES for instance, AES is a symmetric
00:25:28.300 --> 00:25:33.540
key crypto algorithm. Again, you encrypt
messages, you transfer them over a public
00:25:33.540 --> 00:25:40.000
channel, this time with both sides having
the key. You can also use that for
00:25:40.000 --> 00:25:47.830
storage. AES internally uses a 4x4 state
matrix for 4x4 bytes and it runs through
00:25:47.830 --> 00:25:54.390
ten rounds which are S-box, which
basically replaces a byte by another byte,
00:25:54.390 --> 00:25:59.030
some shifting of rows in this matrix, some
mixing of the columns, and then the round
00:25:59.030 --> 00:26:03.150
keys is added which is computed from the
AES key that you provided to the
00:26:03.150 --> 00:26:08.680
algorithm. And if we look at the last
three rounds because we want to, again,
00:26:08.680 --> 00:26:12.090
mount a fault attack, and there are
different differential fault attacks on
00:26:12.090 --> 00:26:18.410
AES. If you look at the last rounds,
because the way of this algorithm works is
00:26:18.410 --> 00:26:22.870
it propagates, changes, differences
through this algorithm. If you'd look at
00:26:22.870 --> 00:26:28.300
the state matrix, which only has a
difference in the top left corner, then
00:26:28.300 --> 00:26:33.830
this is how the state will propagate
through the 9th and 10th round. And you
00:26:33.830 --> 00:26:42.470
can put up formulas to compute possible
values for the state up there. If you have
00:26:42.470 --> 00:26:47.760
different, if you have encryption, which
only have a difference there in exactly
00:26:47.760 --> 00:26:57.350
that single state byte. Now, how does this
work in practice? Well, today everyone is
00:26:57.350 --> 00:27:02.200
using AES-NI because that's super fast.
That's, again, an instruction set
00:27:02.200 --> 00:27:07.510
extension by Intel and it's super fast.
Kit: Oh okay, I want to have a go. Right,
00:27:07.510 --> 00:27:11.970
so let me have a look if I can break some
of these AES-NI instructions. So I'm to
00:27:11.970 --> 00:27:16.040
come at this slightly differently. Last
time I waited for a multiplication fault,
00:27:16.040 --> 00:27:19.710
I'm going to do something slightly
different. What I'm going to do is put in
00:27:19.710 --> 00:27:26.680
a loop two AES encryptions. And I wrote
this using Intel's code, I should say I we
00:27:26.680 --> 00:27:32.760
wrote this using Intel's code, example
code. This should never fault. And we know
00:27:32.760 --> 00:27:36.580
what we're looking for. What we're looking
for is a fault in the eighth round. So
00:27:36.580 --> 00:27:42.370
let's see if we get faults with this. So
the first thing is I'm going to start at
00:27:42.370 --> 00:27:47.510
minus 262 millivolt. What's interesting is
that you have to undervolt more when it's
00:27:47.510 --> 00:27:57.350
cold so you can tell at what time of day I
ran these. Oh I got a fault, I got a fault.
00:27:57.350 --> 00:28:01.950
Well, unfortunately. Where did that?
That's actually in the fourth round. I'm
00:28:01.950 --> 00:28:04.480
I'm obviously, eh fifth round, okay.
Daniel: You can't do anything with that.
00:28:04.480 --> 00:28:09.530
Kit: You can't do anything, again in the
fifth round. Can't do anything with that,
00:28:09.530 --> 00:28:14.800
fifth round again. Oh! Oh we got one. We
got one in the eighth round. And so it
00:28:14.800 --> 00:28:20.710
means I can take these two ciphertext and
I can use the differential fault attack. I
00:28:20.710 --> 00:28:26.620
actually ran this twice in order to get
two pairs of faulty output because it made
00:28:26.620 --> 00:28:30.650
it so much easier. And again, thank you to
somebody on the Internet for having
00:28:30.650 --> 00:28:34.750
written a differential fault analysis
attack for me. You don't, you don't need
00:28:34.750 --> 00:28:39.470
two, but it just makes it easy for the
presentation. So I'm now going to compare.
00:28:39.470 --> 00:28:44.690
Let me just pause that a second, I used
somebody else's differential fault attack
00:28:44.690 --> 00:28:49.600
and it gave me in one, for the first pair
it gave me 500 possible keys and for the
00:28:49.600 --> 00:28:54.470
second it gave me 200 possible keys. I'm
overlapping them. And there was only one
00:28:54.470 --> 00:28:59.860
key that matched both. And that's the key
that came out. And let's just again check
00:28:59.860 --> 00:29:05.970
inside the source code, does that key
exist? What is the key? And yeah, that is
00:29:05.970 --> 00:29:09.590
the key. So, again what I've...
Daniel: That is not a very good key,
00:29:09.590 --> 00:29:14.210
though.
Kit: No, Ehhh... I think, if you think
00:29:14.210 --> 00:29:17.640
about randomness, it's as good as any
other. Anyway, ehhh...
00:29:17.640 --> 00:29:21.470
Laughter
Kit: What have I done? I have flipped a
00:29:21.470 --> 00:29:29.370
bit inside SGX to create a fault in AES
New Instruction set that has enabled me to
00:29:29.370 --> 00:29:33.870
get the AES key out of SGX. You shouldn't
be able to do that.
00:29:33.870 --> 00:29:40.070
Daniel: So. So now that we have multiple
attacks, we should think about a logo and
00:29:40.070 --> 00:29:43.280
a name, right?
Kit: This one better be good because the
00:29:43.280 --> 00:29:46.960
other one wasn't very good.
Daniel: No, seriously, we are already
00:29:46.960 --> 00:29:47.960
soon...
Kit: Okay.
00:29:47.960 --> 00:29:51.430
Daniel: We are, we will write this out.
Send this to a conference. People will
00:29:51.430 --> 00:29:56.510
like it, right. This is and I already have
a name and a logo for it. Kit: Come on
00:29:56.510 --> 00:29:59.350
then.
Daniel: Crypto Vault Screw Hammer.
00:29:59.350 --> 00:30:02.540
Laughter
Daniel: It's like, we attack crypto in a
00:30:02.540 --> 00:30:07.299
vault, SGX, and it's like a, like the
Clock screw and like Row hammer. And
00:30:07.299 --> 00:30:11.610
like...
Kit: I don't think that's very catchy. But
00:30:11.610 --> 00:30:19.840
let me tell you, it's not just crypto. So
we're faulting multiplication. So surely
00:30:19.840 --> 00:30:23.780
there's another use for this other than
crypto. And this is where something really
00:30:23.780 --> 00:30:27.890
interesting happens. For those of you who
are really good at C you can come and
00:30:27.890 --> 00:30:33.870
explain this to me later. This is a really
simple bit of C. All I'm doing is getting
00:30:33.870 --> 00:30:39.280
an offset of an array and taking the
address of that and putting it into a
00:30:39.280 --> 00:30:43.929
pointer. Why is this interesting? Hmmm,
It's interesting because I want to know
00:30:43.929 --> 00:30:47.800
what the compiler does with that. So I am
going to wave my magic wand and what the
00:30:47.800 --> 00:30:53.030
compiler is going to do is it's going to
make this. Why is that interesting?
00:30:53.030 --> 00:30:58.160
Daniel: Simple pointer arithmetic?
Kit: Hmmm. Well. we know that we can fault
00:30:58.160 --> 00:31:02.290
multiplications. So we're no longer
looking at crypto. We're now looking at
00:31:02.290 --> 00:31:08.860
just memory. So let's see if I can use
this as an attack. So let me try and
00:31:08.860 --> 00:31:12.580
explain what's going on here. On the right
hand side, you can see the undervolting.
00:31:12.580 --> 00:31:16.240
I'm going to create an enclave and I've
put it in debug mode so that I can see
00:31:16.240 --> 00:31:20.360
what's going on. You can see the size of
the enclave because we've got the base and
00:31:20.360 --> 00:31:28.750
the limit of it. And if we look at that in
a diagram, what that's saying is here. If
00:31:28.750 --> 00:31:34.780
I can write anything at the top above
that, that will no longer be encrypted,
00:31:34.780 --> 00:31:41.720
that will be unencrypted. Okay, let's
carry on with that. So, let's just write
00:31:41.720 --> 00:31:46.450
that one statement again and again, that
pointer arithmetic again and again and
00:31:46.450 --> 00:31:53.059
again whilst I'm undervolting and see what
happens. Oh, suddenly it changed and if
00:31:53.059 --> 00:31:57.560
you look at where it's mapped it to, it
has mapped that pointer to memory that is
00:31:57.560 --> 00:32:05.560
no longer inside SGX, it has put it into
untrusted memory. So we're just doing the
00:32:05.560 --> 00:32:10.420
same statement again and again whilst
undervolting. Besh, we've written
00:32:10.420 --> 00:32:14.630
something that was in the enclave out of
the enclave. And I'm just going to display
00:32:14.630 --> 00:32:19.350
the page of memory that we've got there to
show you what it was. And there's the one
00:32:19.350 --> 00:32:24.580
line, it's deadbeef And again, I'm just
going to look in my source code to see
00:32:24.580 --> 00:32:30.030
what it was. Yeah, it's, you know you
know, endianness blah, blah, blah. I have
00:32:30.030 --> 00:32:36.270
now not even used crypto. I have purely
used pointer arithmetic to take something
00:32:36.270 --> 00:32:43.140
that was stored inside Intel's SGX and
moved it into user space where anyone can
00:32:43.140 --> 00:32:46.380
read it.
Daniel: So, yes, I get your point. It's
00:32:46.380 --> 00:32:48.750
more than just crypto, right?
Kit: Yeah.
00:32:48.750 --> 00:32:57.490
Daniel: It's way beyond that. So we, we
leaked RSA keys. We leaked AES keys.
00:32:57.490 --> 00:33:01.260
Kit: Go on... Yeah, we did not just that
though we did memory corruption.
00:33:01.260 --> 00:33:06.340
Daniel: Okay, so. Yeah. Okay. Crypto Vault
Screw Hammer, point taken, is not the
00:33:06.340 --> 00:33:10.980
ideal name, but maybe you could come up
with something. We need a name and a logo.
00:33:10.980 --> 00:33:14.250
Kit: So pressures on me then. Right, here
we go. So it's got to be due to
00:33:14.250 --> 00:33:20.710
undervolting because we're undervolting.
Maybe we can get a pun on vault and volt
00:33:20.710 --> 00:33:26.370
in there somewhere. We're stealing
something, aren't we? We're corrupting
00:33:26.370 --> 00:33:30.590
something. Maybe. Maybe we're plundering
something.
00:33:30.590 --> 00:33:31.880
Daniel: Yeah?
Kit: I know.
00:33:31.880 --> 00:33:32.880
Daniel: No?
00:33:32.880 --> 00:33:37.250
Kit: Let's call it plunder volt.
Daniel: Oh, no, no, no. That's not it.
00:33:37.250 --> 00:33:38.309
That's not a good nane.
Kit: What?
00:33:38.309 --> 00:33:42.710
Daniel: That, no. We need something...
That's really not a good name. People will
00:33:42.710 --> 00:33:51.080
hate this name.
Kit: Wait, wait, wait, wait, wait.
00:33:51.080 --> 00:33:53.870
Daniel: No...
Laughter
00:33:53.870 --> 00:33:57.049
Kit: You can read this if you like,
Daniel.
00:33:57.049 --> 00:34:01.410
Daniel: Okay. I, I think I get it. I, I
think I get it.
00:34:01.410 --> 00:34:16.730
Kit: No, no, I haven't finished.
Laughter
00:34:16.730 --> 00:34:35.329
Daniel: Okay. Yeah, this is really also a
very nice comment. Yes. The quality of the
00:34:35.329 --> 00:34:37.659
videos, I think you did a very good job
there.
00:34:37.659 --> 00:34:40.879
Kit: Thank you.
Daniel: Also, the website really good job
00:34:40.879 --> 00:34:42.619
there.
Kit: So, just to summarize, what we've
00:34:42.619 --> 00:34:52.539
done with plunder volt is: It's a new type
of attack, it breaks the integrity of SGX.
00:34:52.539 --> 00:34:57.059
It's within SGX. We're doing stuff we
shouldn't be able to.
00:34:57.059 --> 00:35:01.050
Daniel: Like AES keys, we leak AES keys,
yeah.
00:35:01.050 --> 00:35:06.319
Kit: And we are retrieving the RSA
signature key.
00:35:06.319 --> 00:35:11.109
Daniel: Yeah. And yes, we induced memory
corruption in bug free code.
00:35:11.109 --> 00:35:20.019
Kit: And we made the Enclave write Secrets
to untrusted memory. This is the paper,
00:35:20.019 --> 00:35:27.609
that's been accepted next year. It is my
first paper, so thank you very much. Kit,
00:35:27.609 --> 00:35:29.930
that's me.
Applause
00:35:29.930 --> 00:35:38.950
Kit: Thank you. David Oswald, Flavio
Garcia, Jo Van Bulck and of course, the
00:35:38.950 --> 00:35:46.411
infamous and Frank Piessens. So all that
really remains for me to do is to say,
00:35:46.411 --> 00:35:49.499
thank you very much for coming...
Daniel: Wait a second, wait a second.
00:35:49.499 --> 00:35:53.440
There's one more thing, I think you
overlooked one of the tweets I added it
00:35:53.440 --> 00:35:56.509
here. You didn't see this slide yet?
Kit: I haven't seen this one.
00:35:56.509 --> 00:36:00.900
Daniel: This one, I really like it.
Kit: It's a slightly ponderous pun on
00:36:00.900 --> 00:36:06.329
Thunderbolt... pirate themed logo.
Daniel: A pirate themed logo. I really
00:36:06.329 --> 00:36:13.079
like it. And if it's a pirate themed logo,
don't you think there should be a pirate
00:36:13.079 --> 00:36:16.210
themed song?
Laughter
00:36:16.210 --> 00:36:25.349
Kit: Daniel, have you written a pirate
theme song? Go on then, play it. Let's,
00:36:25.349 --> 00:36:37.220
let's hear the pirate theme song.
music -- see screen --
00:36:37.220 --> 00:37:09.229
Music: ...Volt down me enclaves yo ho. Aye
but it's fixed with a microcode patch.
00:37:09.229 --> 00:37:30.369
Volt down me enclaves yo ho.
Daniel: Thanks to...
00:37:30.369 --> 00:37:43.869
Applause
Daniel: Thanks to Manuel Weber and also to
00:37:43.869 --> 00:37:47.480
my group at Theo Graz for volunteering for
the choir.
00:37:47.480 --> 00:37:51.980
Laughter
Daniel: And then, I mean, this is now the
00:37:51.980 --> 00:37:58.727
last slide. Thank you for your attention.
Thank you for being here. And we would
00:37:58.727 --> 00:38:02.369
like to answer questions in the Q&A
00:38:02.369 --> 00:38:07.079
Applause
00:38:07.079 --> 00:38:13.789
Herald: Thank you for your great talk. And
thank you some more for the song. If you
00:38:13.789 --> 00:38:18.720
have questions, please line up on the
microphones in the room. First question
00:38:18.720 --> 00:38:22.640
goes to the signal angel, any question
from the Internet?
00:38:22.640 --> 00:38:26.979
Signal-Angel: Not as of now, no.
Herald: All right. Then, microphone number
00:38:26.979 --> 00:38:29.800
4, your question please.
Microphone 4: Hi. Thanks for the great
00:38:29.800 --> 00:38:34.809
talk. So, why does this happen now? I
mean, thanks for the explanation for wrong
00:38:34.809 --> 00:38:38.440
number, but it wasn't clear. What's going
on there?
00:38:38.440 --> 00:38:46.890
Daniel: So, too, if you look at circuits
for the signal to be ready at the output,
00:38:46.890 --> 00:38:53.729
they need, electrons have to travel a bit.
If you increase the voltage, things will
00:38:53.729 --> 00:39:00.430
go faster. So they will, you will have the
output signal ready at an earlier point in
00:39:00.430 --> 00:39:05.089
time. Now the frequency that you choose
for your processor should be related to
00:39:05.089 --> 00:39:08.599
that. So if you choose the frequency too
high, the outputs will not be ready yet at
00:39:08.599 --> 00:39:13.319
this circuit. And this is exactly what
happens, if you reduce the voltage the
00:39:13.319 --> 00:39:17.489
outputs are not ready yet for the next
clock cycle.
00:39:17.489 --> 00:39:22.720
Kit: And interestingly, we couldn't fault
really short instructions. So anything
00:39:22.720 --> 00:39:26.400
like an add or an xor, it was basically
impossible to fault. So they had to be
00:39:26.400 --> 00:39:30.859
complex instructions that probably weren't
finishing by the time the next clock tick
00:39:30.859 --> 00:39:31.950
arrived.
Daniel: Yeah.
00:39:31.950 --> 00:39:35.580
Microphone 4: Thank you.
Herald: Thanks for your answer. Microphone
00:39:35.580 --> 00:39:38.960
number 4 again.
Microphone 4: Hello. It's a very
00:39:38.960 --> 00:39:45.160
interesting theoretical approach I think.
But you were capable to break these crypto
00:39:45.160 --> 00:39:53.049
mechanisms, for example, because you could
do zillions of iterations and you are sure
00:39:53.049 --> 00:39:57.930
to trigger the fault. But in practice,
say, as someone is having a secure
00:39:57.930 --> 00:40:03.859
conversation, is it practical, even close
to a possible too to break it with that?
00:40:03.859 --> 00:40:08.210
Daniel: It totally depends on your threat
model. So what can you do with the
00:40:08.210 --> 00:40:12.789
enclave? If you, we are assuming that we
are running with root privileges here and
00:40:12.789 --> 00:40:17.461
a root privileged attacker can certainly
run the enclave with certain inputs, again
00:40:17.461 --> 00:40:21.970
and again. If the enclave doesn't have any
protection against replay, then certainly
00:40:21.970 --> 00:40:25.759
we can mount an attack like that. Yes.
Microphone 4: Thank you.
00:40:25.759 --> 00:40:30.640
Herald: Signal-Angel your question.
Signal: Somebody asked if the attack only
00:40:30.640 --> 00:40:33.980
applies to Intel or to AMD or other
architectures as well.
00:40:33.980 --> 00:40:37.900
Kit: Oh, good question, I suspect right
now there are people trying this attack on
00:40:37.900 --> 00:40:41.599
AMD in the same way that when clock screw
came out, there were an awful lot of
00:40:41.599 --> 00:40:46.759
people starting to do stuff on Intel as
well. We saw the clock screw attack on ARM
00:40:46.759 --> 00:40:52.460
with frequency. Then we saw ARM with
voltage. Now we've seen Intel with
00:40:52.460 --> 00:40:57.369
voltage. And someone else has done similar
Volt pwn has done something very similar
00:40:57.369 --> 00:41:01.799
to us. And I suspect AMD is the next one.
I guess, because it's not out there as
00:41:01.799 --> 00:41:06.789
much. We've tried to do them in the order
of, you know, scaring people.
00:41:06.789 --> 00:41:10.130
Laughter
Kit: Scaring as many people as possible as
00:41:10.130 --> 00:41:13.789
quickly as possible.
Herald: Thank you for the explanation.
00:41:13.789 --> 00:41:18.319
Microphone number 4.
Microphone 4: Hi. Hey, great. Thanks for
00:41:18.319 --> 00:41:25.339
the representation. Can you get similar
results by Harrower? I mean by tweaking
00:41:25.339 --> 00:41:28.309
the voltage that you provide to the CPU
or...
00:41:28.309 --> 00:41:32.680
Kit: Well, I refer you to my earlier
answer. I know for a fact that there are
00:41:32.680 --> 00:41:37.099
people doing this right now with physical
hardware, seeing what they can do. Yes,
00:41:37.099 --> 00:41:40.569
and I think it will not be long before
that paper comes out.
00:41:40.569 --> 00:41:46.519
Microphone 4: Thank you.
Herald: Thanks. Microphone number one.
00:41:46.519 --> 00:41:51.150
Your question. Sorry, microphone 4 again,
sorry.
00:41:51.150 --> 00:41:57.920
Microphone 4: Hey, thanks for the talk.
Two small questions. One, why doesn't
00:41:57.920 --> 00:42:07.789
anything break inside SGX when you do
these tricks? And second one, why when you
00:42:07.789 --> 00:42:14.539
write outside the enclaves memory, their
value is not encrypted.
00:42:14.539 --> 00:42:21.839
Kit: So the enclave is an encrypted area
of memory. So when it points to an
00:42:21.839 --> 00:42:24.260
unencrypted, it's just
going to write it to the unencrypted
00:42:24.260 --> 00:42:28.650
memory. Does that make sense?
Daniel: From the enclaves perspective,
00:42:28.650 --> 00:42:33.079
none of the memory is encrypted. This is
just transparent to the enclave. So if the
00:42:33.079 --> 00:42:36.680
enclave will write to another memory
location. Yes, it just won't be encrypted.
00:42:36.680 --> 00:42:40.609
Kit Yeah. And what's happening is we're
getting flips in the registers. Which is
00:42:40.609 --> 00:42:44.079
why I think we're not getting an integrity
check because the enclave is completely
00:42:44.079 --> 00:42:48.150
unaware that anything's even gotten wrong.
It's got a value in its memory and it's
00:42:48.150 --> 00:42:51.230
gonna use it.
Daniel: Yeah. The integrity check is only
00:42:51.230 --> 00:42:55.210
on the on the memory that you logged from
RAM. Yeah.
00:42:55.210 --> 00:43:02.589
Herald: Okay, microphone number 7.
Microphone 7: Yeah. Thank you. Interesting
00:43:02.589 --> 00:43:11.950
work. I was wondering, you showed us the
example of the code that wrote outside the
00:43:11.950 --> 00:43:17.229
Enclave Memory using simple pointer
arithmetics. Have you been able to talk to
00:43:17.229 --> 00:43:23.559
Intel why this memory access actually
happens? I mean, you showed us the output
00:43:23.559 --> 00:43:28.569
of the program. It crashes, but
nevertheless, it writes the result to the
00:43:28.569 --> 00:43:34.469
resulting memory address. So there must be
something wrong, like the attack that
00:43:34.469 --> 00:43:39.979
happened two years ago at the Congress
about, you know, all that stuff.
00:43:39.979 --> 00:43:46.030
Daniel: So generally enclaves can read and
write any memory location in their host
00:43:46.030 --> 00:43:52.819
application. We have also published papers
that basically argued that this might not
00:43:52.819 --> 00:44:00.140
be a good idea, good design decision. But
that's the current design. And the reason
00:44:00.140 --> 00:44:04.849
is that this makes interaction with the
enclave very easy. You can just place your
00:44:04.849 --> 00:44:09.279
payload somewhere in the memory. Hand the
pointer to the enclave and the enclave can
00:44:09.279 --> 00:44:13.810
use the data from there, maybe copy it
into the enclave memory if necessary, or
00:44:13.810 --> 00:44:19.579
directly work on the data. So that's why
this memory access to the normal memory
00:44:19.579 --> 00:44:24.500
region is not illegal.
Kit: And if you want to know more, you can
00:44:24.500 --> 00:44:29.450
come and find Daniel afterwards.
Herald: Okay. Thanks for the answer.
00:44:29.450 --> 00:44:32.730
Signal-Angel, the questions from the
Internet.
00:44:32.730 --> 00:44:39.140
Signal-Angel: Yes. The question came up. If, how
stable the system you're attacking with
00:44:39.140 --> 00:44:42.150
the hammering
is while you're performing their attack.
00:44:42.150 --> 00:44:46.180
Kit: It's really stable. Once I've been
through three months of crashing the
00:44:46.180 --> 00:44:49.720
computer. I got to a point where I had a
really, really good frequency voltage
00:44:49.720 --> 00:44:55.520
combination. And we did discover on all
Intel chips, it was different. So even, on
00:44:55.520 --> 00:44:59.280
what looked like and we bought almost an
identical little nook, we bought one with
00:44:59.280 --> 00:45:05.670
exactly the same spec and it had a
different sort of frequency voltage model.
00:45:05.670 --> 00:45:09.719
But once we'd done this sort of
benchmarking, you could pretty much do any
00:45:09.719 --> 00:45:14.509
attack without it crashing at all.
Daniel: But without this benchmarking,
00:45:14.509 --> 00:45:17.729
it's true. We would often reboot.
Kit: That was a nightmare yeah, I wish I'd
00:45:17.729 --> 00:45:20.440
done that the beginning. It would've saved
me so much time.
00:45:20.440 --> 00:45:25.019
Herald: Thanks again for answering.
Microphone number 4 your question.
00:45:25.019 --> 00:45:29.260
Microphone 4: Can Intel fix this with a
microcode update?
00:45:29.260 --> 00:45:36.549
Daniel: So, there are different approaches
to this. Of course, the quick fix is to
00:45:36.549 --> 00:45:41.690
remove the access to the MSR, which is of
course inconvenient because you can't
00:45:41.690 --> 00:45:45.240
undervolt your system anymore. So maybe
you want to choose whether you want to use
00:45:45.240 --> 00:45:50.660
SGX or want to have a gaming computer
where you undervolt the system or control
00:45:50.660 --> 00:45:56.219
the voltage from software. But is this a
real fix? I don't know. I think there are
00:45:56.219 --> 00:45:58.729
more vectors, right?
Kit: Yeah.But, well I'll be interested to
00:45:58.729 --> 00:46:01.210
see what they're going to do with the next
generation of chips.
00:46:01.210 --> 00:46:04.609
Daniel: Yeah.
Herald: All right. Microphone number 7,
00:46:04.609 --> 00:46:08.859
what's your question?
Microphone 7: Yes, similarly to the other
00:46:08.859 --> 00:46:14.170
question, is there a way you can prevent
such attacks when writing code that runs
00:46:14.170 --> 00:46:17.820
in the secure enclave?
Kit: Well, no. That's the interesting
00:46:17.820 --> 00:46:22.739
thing, it's really hard to do. Because we
weren't writing code with bugs, we were
00:46:22.739 --> 00:46:26.999
just writing normal pointer arithmetic.
Normal crypto. If anywhere in your code,
00:46:26.999 --> 00:46:29.549
you're using a multiplication. It can be
attacked.
00:46:29.549 --> 00:46:34.750
Daniel: But of course, you could use fault
resistant implementations inside the
00:46:34.750 --> 00:46:39.160
enclave. Whether that is a practical
solution is yet to be determined
00:46:39.160 --> 00:46:41.859
Kit: Oh yes, yea, right, you could write
duplicate code and do comparison things
00:46:41.859 --> 00:46:46.829
like that. But if, yeah.
Herald: Okay. Microphone number 3. What's
00:46:46.829 --> 00:46:47.829
your question?
00:46:47.829 --> 00:46:53.390
Microphone 3: Hi. I can't imagine Intel
being very happy about this and recently
00:46:53.390 --> 00:46:57.450
they were under fire for how they were
handling a coordinated disclosure. So can
00:46:57.450 --> 00:47:01.299
you summarize experience?
Kit: They were... They were really nice.
00:47:01.299 --> 00:47:06.380
They were really nice. We disclosed really
early, like before we had all of the
00:47:06.380 --> 00:47:08.960
attacks.
Daniel: We just had a POC at that point.
00:47:08.960 --> 00:47:11.239
Kit: Yeah.
Daniel: Yeah, Simply POC. Very simple.
00:47:11.239 --> 00:47:14.890
Kit: They've been really nice. They wanted
to know what we were doing. They wanted to
00:47:14.890 --> 00:47:18.660
see all our attacks. I found them lovely.
Daniel: Yes.
00:47:18.660 --> 00:47:21.880
Kit: Am I allowed to say that?
Laughter
00:47:21.880 --> 00:47:24.859
Daniel: I mean, they also have interest
in...
00:47:24.859 --> 00:47:26.950
Kit: Yeah.
Daniel ...making these processes smooth.
00:47:26.950 --> 00:47:30.279
So that vulnerability researchers also
report to them.
00:47:30.279 --> 00:47:32.039
Kit: Yeah.
Daniel: Because if everyone says, oh this
00:47:32.039 --> 00:47:37.700
was awful, then they will also not get a
lot of reports. But if they do their job
00:47:37.700 --> 00:47:39.849
well and they did in our case.
Kit: Yeah.
00:47:39.849 --> 00:47:44.450
Daniel: Then of course, it's nice.
Herald: Okay. Microphone number 4...
00:47:44.450 --> 00:47:48.499
Danie: We even got a bug bounty.
Kit: We did get a bug bounty. I didn't
00:47:48.499 --> 00:47:51.499
want to mention that because I haven't
told my university yet.
00:47:51.499 --> 00:47:55.430
Laughter
Microphone 4: Thank you. Thank you for the
00:47:55.430 --> 00:48:01.799
funny talk. If I understood, you're right,
it means to really be able to exploit
00:48:01.799 --> 00:48:07.249
this. You need to do some benchmarking on
the machine that you want to exploit. Do
00:48:07.249 --> 00:48:15.239
you see any way to convert this to a
remote exploit? I mean, that to me, it
00:48:15.239 --> 00:48:19.650
seems you need physical access right now
because you need to reboot the machine.
00:48:19.650 --> 00:48:23.859
Kit: If you've done benchmarking on an
identical machine, I don't think you would
00:48:23.859 --> 00:48:27.039
have to have physical access.
Daniel: But you would have to make sure
00:48:27.039 --> 00:48:29.549
that it's really an identical machine.
Kit: Yeah.
00:48:29.549 --> 00:48:33.499
Daniel: But in the cloud you will find a
lot of identical machines.
00:48:33.499 --> 00:48:41.119
Laughter
Herald: Okay, microphone number 4 again.
00:48:41.119 --> 00:48:46.059
Daniel: Also, as we said, like the
temperature plays an important role.
00:48:46.059 --> 00:48:47.650
Kit: Yeah.
Daniel: You will also in the cloud find a
00:48:47.650 --> 00:48:52.390
lot of machines at similar temperatures
Kit: And there was, there is obviously
00:48:52.390 --> 00:48:55.569
stuff that we didn't show you. We did
start measuring the total amount of clock
00:48:55.569 --> 00:49:00.259
ticks it took to do maybe 10 RSA
encryption. And then we did start doing
00:49:00.259 --> 00:49:03.820
very specific timing attacks. But
obviously it's much easier to just do
00:49:03.820 --> 00:49:10.452
10000 of them and hope that one faults.
Herald: All right. Seems there are no
00:49:10.452 --> 00:49:13.940
further questions. Thank you very much for
your talk. For your research and for
00:49:13.940 --> 00:49:15.140
answering all the questions.
Applause
00:49:15.140 --> 00:49:18.529
Kit: Thank you.
Daniel: Thank you.
00:49:18.529 --> 00:49:22.479
postroll music
00:49:22.479 --> 00:49:48.000
subtitles created by c3subtitles.de
in the year 20??. Join, and help us!