WEBVTT
00:00:00.000 --> 00:00:14.790
36C3 preroll music
00:00:14.790 --> 00:00:25.539
Herald: Our next speaker is way is paved
with broken trust zones. He's no stranger
00:00:25.539 --> 00:00:31.599
to breaking ARM's, equipment or crypto
wallets or basically anything he touches.
00:00:31.599 --> 00:00:39.591
It just dissolves in his fingers. He's one
of Forbes, 30 under 30s in tech. And
00:00:39.591 --> 00:00:42.840
please give a warm round of applause to
Thomas Roth.
00:00:42.840 --> 00:00:48.100
Applause.
00:00:48.100 --> 00:00:54.680
Thomas: Test, okay. Wonderful. Yeah.
Welcome to my talk. TrustZone-M: Hardware
00:00:54.680 --> 00:01:00.630
attacks on ARMv8-M security features. My
name is Thomas Roth. You can find me on
00:01:00.630 --> 00:01:05.860
Twitter. I'm @stacksmashing and I'm a
security researcher, consultant and
00:01:05.860 --> 00:01:11.049
trainer affiliated with a couple of
companies. And yeah, before we can start,
00:01:11.049 --> 00:01:15.990
I need to to thank some people. So first
off, Josh Datko and Dimitri Nedospasov
00:01:15.990 --> 00:01:20.110
who've been super helpful at anytime I was
stuck somewhere, or just wanted some
00:01:20.110 --> 00:01:25.969
feedback. They immediately helped me. And
also Colin O'Flynn, who gave me constant
00:01:25.969 --> 00:01:30.729
feedback and helped me with some troubles,
gave me tips and so on. And so without
00:01:30.729 --> 00:01:36.909
these people and many more who paved the
way towards this research, I wouldn't be
00:01:36.909 --> 00:01:41.520
here. Also, thanks to NXP and Microchip
who I had to work with as part of this
00:01:41.520 --> 00:01:47.950
talk. And it was awesome. I had a lot of
very bad vendor experiences, but these two
00:01:47.950 --> 00:01:54.799
were really nice to work with. Also some
prior work. So Colin O'Flynn and Alex
00:01:54.799 --> 00:01:59.499
Dewar released a paper, I guess last year
or this year "On-Device Power Analysis
00:01:59.499 --> 00:02:04.270
Across Hardware Security Domains". And
they basically looked at TrustZone from a
00:02:04.270 --> 00:02:10.301
differential power analysis viewpoint and
otherwise TrustZone-M is pretty new, but
00:02:10.301 --> 00:02:15.860
lots of work has been done on the big or
real TrustZone and also lots and lots of
00:02:15.860 --> 00:02:21.440
works on fault injection would be far too
much to list here. So just google fault
00:02:21.440 --> 00:02:26.220
injection and you'll see what I mean.
Before we start, what is TrustZone-M? So
00:02:26.220 --> 00:02:31.890
TrustZone-M is the small TrustZone. It's
basically a simplified version of the big
00:02:31.890 --> 00:02:35.940
TrustZone that you find on Cortex-A
processors. So basically if you have an
00:02:35.940 --> 00:02:40.280
Android phone, chances are very high that
your phone actually runs TrustZone and
00:02:40.280 --> 00:02:44.950
that, for example, your key store of
Android is backed by TrustZone. And
00:02:44.950 --> 00:02:50.620
TrustZone basically splits the CPU into a
secure and a non-secure world. And so, for
00:02:50.620 --> 00:02:54.340
example, you can say that a certain
peripheral should only be available to the
00:02:54.340 --> 00:02:58.190
secure world. So, for example, if you have
a crypto accelerator, you might only want
00:02:58.190 --> 00:03:03.990
to use it in the secure world. It also, if
you're wondering what's the difference to
00:03:03.990 --> 00:03:10.870
an MPU - it also comes with two MPUs.
Sorry, not MMUs, MPUs. And so last year we
00:03:10.870 --> 00:03:14.650
gave a talk on bitcoin wallets. And so
let's take those as an example on a
00:03:14.650 --> 00:03:19.730
bitcoin wallet you often have different
apps, for example, for Bitcoin, Dogecoin
00:03:19.730 --> 00:03:24.590
or Monaro, and then underneath you have an
operating system. The problem is kind of
00:03:24.590 --> 00:03:28.620
this operating system is very complex
because it has to handle graphics
00:03:28.620 --> 00:03:33.060
rendering and so on and so forth. And
chances are high that it gets compromised.
00:03:33.060 --> 00:03:37.900
And if it gets compromised, all your funds
are gone. And so with TrustZone, you could
00:03:37.900 --> 00:03:43.380
basically have a second operating system
separated from your normal one that
00:03:43.380 --> 00:03:47.250
handles all the important stuff like
firmware update, key store attestation and
00:03:47.250 --> 00:03:52.930
so on and reduces your attack surface. And
the reason I actually looked at
00:03:52.930 --> 00:03:57.280
TrustZone-M is we got a lot of requests
for consulting on TrustZone-M. So
00:03:57.280 --> 00:04:02.510
basically, after our talk last year, a lot
of companies reached out to us and said,
00:04:02.510 --> 00:04:07.100
okay, we want to do this, but more
securely. And a lot of them try to use
00:04:07.100 --> 00:04:12.190
TrustZone-M for this. And so far there's
been, as far as I know, little public
00:04:12.190 --> 00:04:16.780
research into TrustZone-M and whether it's
protected against certain types of
00:04:16.780 --> 00:04:21.250
attacks. And we also have companies that
start using them as secure chips. So, for
00:04:21.250 --> 00:04:24.990
example, in the automotive industry, I
know somebody who was thinking about
00:04:24.990 --> 00:04:28.810
putting them into car keys. I know about
some people in the payment industry
00:04:28.810 --> 00:04:34.820
evaluating this. And as said, hardware
wallets. And one of the terms that come up
00:04:34.820 --> 00:04:40.469
again and again is this is a secure chip.
But I mean, what is the secure chip
00:04:40.469 --> 00:04:45.130
without a threat model? There's no such
thing as a secure chip because there are
00:04:45.130 --> 00:04:49.310
so many attacks and you need to have a
threat model to understand what are you
00:04:49.310 --> 00:04:53.280
actually protecting against. So, for
example, a chip might have software
00:04:53.280 --> 00:04:59.080
features or hardware features that make
the software more secure, such as NX bit
00:04:59.080 --> 00:05:03.229
and so on and so forth. And on the other
hand, you have hardware attacks, for
00:05:03.229 --> 00:05:08.460
example, debug port side channel attacks
and fault injection. And often the
00:05:08.460 --> 00:05:14.289
description of a chip doesn't really tell
you what it's protecting you against. And
00:05:14.289 --> 00:05:19.139
often I would even say it's misleading in
some cases. And so you will see, oh, this
00:05:19.139 --> 00:05:22.850
is a secure chip and you ask marketing and
they say, yeah, it has the most modern
00:05:22.850 --> 00:05:28.310
security features. But it doesn't really
specify whether they are, for example,
00:05:28.310 --> 00:05:31.759
protecting against fault injection attacks
or whether they consider this out of
00:05:31.759 --> 00:05:37.530
scope. In this talk, we will exclusively
look at hardware attacks and more
00:05:37.530 --> 00:05:42.439
specifically, we will look at fault
injection attacks on TrustZone-M. And so
00:05:42.439 --> 00:05:47.180
all of the attacks we're going to see are
local to the device only you need to have
00:05:47.180 --> 00:05:52.470
it in your hands. And there's no chance,
normally, of remotely exploiting them.
00:05:52.470 --> 00:05:58.599
Yeah. So this will be our agenda. We will
start with a short introduction of
00:05:58.599 --> 00:06:01.990
TrustZone-M, which will have a lot of
theory on like memory layouts and so on.
00:06:01.990 --> 00:06:05.610
We will talk a bit about the fault-
injection setup and then we will start
00:06:05.610 --> 00:06:13.229
attacking real chips. These 3, as you will
see. So on a Cortex-M processor you have a
00:06:13.229 --> 00:06:17.270
flat memory map. You don't have a memory
management unit and all your peripherals,
00:06:17.270 --> 00:06:21.719
your flash, your ram, it's all mapped to a
certain address in memory and TrustZone-M
00:06:21.719 --> 00:06:27.669
allows you to partition your flash or your
ram into secure and non secure parts. And
00:06:27.669 --> 00:06:31.400
so, for example, you could have a tiny
secure area because your secret code is
00:06:31.400 --> 00:06:36.909
very small and a big non secure area. The
same is true for Ram and also for the
00:06:36.909 --> 00:06:42.569
peripherals. So for example, if you have a
display and a crypto engine and so on. You
00:06:42.569 --> 00:06:48.599
can decide whether these peripherals
should be secure or non secure. And so
00:06:48.599 --> 00:06:53.419
let's talk about these two security
states: secure and non secure. Well, if
00:06:53.419 --> 00:06:57.949
you have code running in secure flash or
you have secure code running, it can call
00:06:57.949 --> 00:07:02.729
anywhere into the non secure world. It's
basically the highest privilege level you
00:07:02.729 --> 00:07:08.009
can have. And so there's no protection
there. However, the opposite, if we tried
00:07:08.009 --> 00:07:12.479
to go from the non secure world and to the
secure world would be insecure because,
00:07:12.479 --> 00:07:15.469
for example, you could jump to the parts
of the code that are behind certain
00:07:15.469 --> 00:07:20.330
protections and so on. And so that's why,
if you tried to jump from an unsecured
00:07:20.330 --> 00:07:26.749
code into a secure code, it will cause an
exception. And to handle that, there's a
00:07:26.749 --> 00:07:32.249
third memory state which is called non
secure callable. And as the name implies,
00:07:32.249 --> 00:07:37.909
basically you're non secure code can call
into the non secure callable code. More
00:07:37.909 --> 00:07:43.210
specifically, it can only call to non
secure callable code addresses where
00:07:43.210 --> 00:07:49.569
there's an SG instruction which stands for
Secure Gateway. And the idea behind the
00:07:49.569 --> 00:07:53.539
secure gateway is that if you have a non
secure kernel running, you probably also
00:07:53.539 --> 00:07:57.610
have a secure kernel of running. And
somehow this secure kernel will expose
00:07:57.610 --> 00:08:02.520
certain system calls, for example. And so
we want to somehow call from the non
00:08:02.520 --> 00:08:09.069
secure kernel into these system calls, but
as I've just mentioned, we can't do that
00:08:09.069 --> 00:08:15.039
because this will unfortunately cause an
exception. And so the way this is handled
00:08:15.039 --> 00:08:19.729
on TrustZone-M is that you create so-
called secure gateway veneer functions.
00:08:19.729 --> 00:08:24.689
These are very short functions in the non
secure callable area. And so if we want,
00:08:24.689 --> 00:08:29.650
for example, to call the load key system
call, we would call the load key veneer
00:08:29.650 --> 00:08:35.370
function, which in turn would call the
real load key function. And these veneer
00:08:35.370 --> 00:08:40.199
functions are super short. So if you look
at the disassembly of them, it's like two
00:08:40.199 --> 00:08:44.120
instructions. It's the secure gateway
instruction and then a branch instruction
00:08:44.120 --> 00:08:51.630
to what's your real function. And so if we
combine this, we end up with this diagram
00:08:51.630 --> 00:08:57.199
secure can call into non secure, non
secure, can call into NSC and NSC can call
00:08:57.199 --> 00:09:04.190
into your secure world. But how do we
manage these memory states? How do we know
00:09:04.190 --> 00:09:09.300
what security state does an address have?
And so for this in TrustZone-M, we use
00:09:09.300 --> 00:09:13.940
something called attribution units and
there're by default there are two
00:09:13.940 --> 00:09:19.089
attribution units available. The first one
is the SAU the Security Attribution Unit,
00:09:19.089 --> 00:09:24.430
which is standard across chips. It's
basically defined by ARM how you use this.
00:09:24.430 --> 00:09:29.490
And then there's the IDAU. The
Implementation Defined Attribution Unit,
00:09:29.490 --> 00:09:34.070
which is basically custom to the silicon
vendor, but can also be the same across
00:09:34.070 --> 00:09:41.259
several chips. And to get the security
state of an address, the security
00:09:41.259 --> 00:09:47.310
attribution of both the SAU and the IDAU
are combined and whichever one has the
00:09:47.310 --> 00:09:53.149
higher privilege level will basically win.
And so let's say our SAU says this address
00:09:53.149 --> 00:09:59.209
is secure and our IDAU says this address
is non secure the SAU wins because it's
00:09:59.209 --> 00:10:05.880
the highest privilege level. And basically
our address would be considered secure.
00:10:05.880 --> 00:10:12.340
This is a short table. If both the SAU and
the IDAU agree, we will be non secure if
00:10:12.340 --> 00:10:17.240
both say, hey, this is secure, it will be
secure. However, if they disagree and the
00:10:17.240 --> 00:10:22.640
SAU says, hey, this address is secure the
IDAU says it's non secure, it will still
00:10:22.640 --> 00:10:27.459
be secure because secure is to have
privilege level. The opposite is true. And
00:10:27.459 --> 00:10:33.850
with even with non secure callable, secure
is more privileged than NSC. And so secure
00:10:33.850 --> 00:10:41.170
will win. But if we mix NS and NSC, we get
non-secular callable. Okay. My initial
00:10:41.170 --> 00:10:45.880
hypothesis when I read all of this was if
we break or disable the attribution units,
00:10:45.880 --> 00:10:52.220
we probably break the security. And so to
break these, we have to understand them.
00:10:52.220 --> 00:10:57.560
And so let's look at the SAU the security
attribution unit. It's standardized by
00:10:57.560 --> 00:11:02.430
ARM. It's not available on all chips. And
it basically allows you to create memory
00:11:02.430 --> 00:11:08.740
regions with different security states.
So, for example, if the SAU is turned off,
00:11:08.740 --> 00:11:13.190
everything will be considered secure. And
if we turn it on, but no regions are
00:11:13.190 --> 00:11:16.990
configured, still, everything will be
secure. We can then go and add, for
00:11:16.990 --> 00:11:23.850
example, address ranges and make them NSC
or non secure and so on. And this is done
00:11:23.850 --> 00:11:28.920
very, very easily. You basically have
these five registers. You have the SAU
00:11:28.920 --> 00:11:34.890
control register where you basically can
turn it on or off. You have the SAU type,
00:11:34.890 --> 00:11:38.329
which gives you the number of supported
regions on your platform because this can
00:11:38.329 --> 00:11:42.779
be different across different chips. And
then we have the region number register,
00:11:42.779 --> 00:11:46.149
which you use to select the region you
want to configure and then you set the
00:11:46.149 --> 00:11:50.460
base address and the limit address. And
that's basically it. So, for example, if
00:11:50.460 --> 00:11:57.380
we want to set region zero, we simply set
the RNR register to zero. Then we set the
00:11:57.380 --> 00:12:05.649
base address to 0x1000. We set the limit
address to 0x1FE0, which is identical to
00:12:05.649 --> 00:12:08.970
1FFF because there are some other bits
behind there that we don't care about
00:12:08.970 --> 00:12:14.910
right now. And then we turn on the
security attribution unit and now our
00:12:14.910 --> 00:12:19.420
memory range is marked as secure if you
want to create a second region we simply
00:12:19.420 --> 00:12:25.980
change RNR to, for example, 1 again insert
some nice addresses. Turn on the SAU and
00:12:25.980 --> 00:12:33.860
we have a second region this time from
4000 to 5FFF. So to summarize, we have
00:12:33.860 --> 00:12:40.470
three memory security states. We have S
secure and we have NSC non secure callable
00:12:40.470 --> 00:12:46.149
and we have NS non secure. We also have
the two attribution units, the SAU
00:12:46.149 --> 00:12:53.070
standard by ARM and the IDAU which is
potentially custom we will use SAU and
00:12:53.070 --> 00:13:00.120
IDAU a lot. So this was very important.
Cool. Let's talk about fault injection. So
00:13:00.120 --> 00:13:06.060
as I've mentioned, we want to use fault
injection to compromise TrustZone. And the
00:13:06.060 --> 00:13:10.740
idea behind fault injection or as it's
also called glitching is to introduce
00:13:10.740 --> 00:13:14.610
faults into a chip. So, for example, you
cut the power for a very short amount of
00:13:14.610 --> 00:13:19.310
time while you change the period of the
clock signal or even you could go and
00:13:19.310 --> 00:13:23.600
inject electromagnetic shocks in your
chip. You can also shoot at it with a
00:13:23.600 --> 00:13:29.170
laser and so on and so forth. Lots of ways
to do this. And the goal of this is to is
00:13:29.170 --> 00:13:34.399
to cause undefined behavior. And in this
talk, we will specifically look at
00:13:34.399 --> 00:13:40.440
something called voltage glitching. And so
the idea behind voltage glitching is that
00:13:40.440 --> 00:13:44.930
we cut the power to the chip for very,
very short amount of time at a very
00:13:44.930 --> 00:13:49.100
precisely timed moment. And this will
cause some interesting behavior. So
00:13:49.100 --> 00:13:56.720
basically, if you would look at this on an
oscilloscope, we would basically have a
00:13:56.720 --> 00:14:02.569
stable voltage, stable voltage, stable
voltage, and then suddenly it drops and
00:14:02.569 --> 00:14:08.100
immediately returns. And this drop will
only be a couple of nanoseconds long. And
00:14:08.100 --> 00:14:12.760
so, for example, you can have glitches
that are 10 nanoseconds long or 15
00:14:12.760 --> 00:14:18.829
nanoseconds long and so on. Depends on
your chip. And yeah. And this allows you
00:14:18.829 --> 00:14:24.230
to do different things. So, for example, a
glitch can allow you to skip instructions.
00:14:24.230 --> 00:14:29.110
It can corrupt flash reads or flash
writes. It can corrupt memory registers or
00:14:29.110 --> 00:14:34.920
register reads and writes. And skipping
instructions for me is always the most
00:14:34.920 --> 00:14:40.000
interesting one, because it allows you to
directly go from disassembly to
00:14:40.000 --> 00:14:45.079
understanding what you can potentially
jump over. So, for example, if we have
00:14:45.079 --> 00:14:50.610
some code, this would be a basic firmware
boot up code. We have an initialized
00:14:50.610 --> 00:14:55.439
device function. Then we have a function
that basically verifies the firmware
00:14:55.439 --> 00:15:00.339
that's in flash and then we have this
boolean check whether our firmware was
00:15:00.339 --> 00:15:05.329
valid. And now if we glitch at just the
right time, we might be able to glitch
00:15:05.329 --> 00:15:12.879
over this check and boot our potentially
compromised firmware, which is super nice.
00:15:12.879 --> 00:15:19.480
So how does this relate to TrustZone?
Well, if we manage to glitch over enable
00:15:19.480 --> 00:15:25.899
TrustZone, we might be able to break
TrustZone. So how do you actually do this?
00:15:25.899 --> 00:15:30.810
Well, we need something to wait for a
certain delay and generate a pulse at just
00:15:30.810 --> 00:15:36.250
the right time with very high precision.
We are talking about nano seconds here,
00:15:36.250 --> 00:15:40.259
and we also need something to drop the
power to the target. And so if you need
00:15:40.259 --> 00:15:46.450
precise timing and so on, what works very
well is an FPGA. And so, for example, the
00:15:46.450 --> 00:15:51.649
code that was released as part of this all
runs on the Lattice iCEstick, which is
00:15:51.649 --> 00:15:56.610
roughly 30 bucks and you need a cheap
MOSFET and so together this is like thirty
00:15:56.610 --> 00:16:02.440
one dollars of equipment. And on a setup
side, this looks something like this. You
00:16:02.440 --> 00:16:06.830
would have your FPGA, which has a trigger
input. And so, for example, if you want to
00:16:06.830 --> 00:16:10.430
glitch something doing the boot up of a
chip, you could connect this to the reset
00:16:10.430 --> 00:16:14.769
line of the chip. And then we have an
output for the glitch pulse. And then if
00:16:14.769 --> 00:16:20.820
we hook this all up, we basically have our
power supply to the chip run over a
00:16:20.820 --> 00:16:26.529
MOSFET. And then if the glitch pulls goes
high, we drop the power to ground and the
00:16:26.529 --> 00:16:33.189
chip doesn't get power for a couple of
nanoseconds. Let's talk about this power
00:16:33.189 --> 00:16:39.360
supply, because a chip has a lot of
different things inside of it. So, for
00:16:39.360 --> 00:16:45.370
example, a microcontroller has a CPU core.
We have a Wi-Fi peripheral. We have GPIO.
00:16:45.370 --> 00:16:50.899
We might have Bluetooth and so on. And
often these peripherals run at different
00:16:50.899 --> 00:16:56.529
voltages. And so while our microcontroller
might just have a 3.3 volt input,
00:16:56.529 --> 00:17:00.079
internally there are a lot of different
voltages at play. And the way these
00:17:00.079 --> 00:17:05.410
voltages are generated often is using
in-chip regulators. And basically these
00:17:05.410 --> 00:17:11.449
regulators connect with the 3.3 voltage in
and then generate the different voltages
00:17:11.449 --> 00:17:16.740
for the CPU core and so on. But what's
nice is that on a lot of chips there are
00:17:16.740 --> 00:17:21.620
behind the core regulator, so called
bypass capacitors, and these external
00:17:21.620 --> 00:17:26.240
capacitors are basically there to
stabilize the voltage because regulators
00:17:26.240 --> 00:17:32.120
tend to have a very noisy output and you
use the capacitor to make it more smooth.
00:17:32.120 --> 00:17:36.730
But if you look at this, this also gives
us direct access to the CPU core power
00:17:36.730 --> 00:17:42.390
supply. And so if we just take a heat gun
and remove the capacitor, we actually kind
00:17:42.390 --> 00:17:46.730
of change the pin out of the processor
because now we have a 3.3 voltage in, we
00:17:46.730 --> 00:17:52.700
have a point to input the core voltage and
we have ground. So we basically gained
00:17:52.700 --> 00:17:59.990
direct access to the internal CPU core
voltage rails. The only problem is these
00:17:59.990 --> 00:18:04.630
capacitors are for a reason. And so if we
remove them, then your chip might stop
00:18:04.630 --> 00:18:09.770
working. But very easy solution. You just
hook up a power supply to it, set it to
00:18:09.770 --> 00:18:14.650
1.2 volts or whatever, and then suddenly
it works. And this also allows you to
00:18:14.650 --> 00:18:23.150
glitch very easily. You just glitch on
your power rail towards the chip. And so
00:18:23.150 --> 00:18:27.450
this is our current setup. So we have the
Lattice iCEstick. We also use a
00:18:27.450 --> 00:18:31.430
multiplexer as an analog switch to cut the
power to the entire device. If we want to
00:18:31.430 --> 00:18:36.779
reboot everything, we have the MOSFET and
we have a power supply. Now hooking this
00:18:36.779 --> 00:18:42.300
all up on a bread board is fun the first
time, it's okay the second time. But the
00:18:42.300 --> 00:18:47.080
third time it begins to really, really
suck. And as soon as something breaks with
00:18:47.080 --> 00:18:52.450
like 100 jumper wires on your desk, the
only way to debug is to start over. And so
00:18:52.450 --> 00:18:57.320
that's why I decided to design a small
hardware platform that combines all of
00:18:57.320 --> 00:19:03.070
these things. So it has an FPGA on it. It
has analog input and it has a lot of
00:19:03.070 --> 00:19:07.560
glitch circuitry and it's called the Mark
Eleven. If you've read William Gibson, you
00:19:07.560 --> 00:19:13.260
might know where this is from. And it
contains a Lattice iCE40, which has a
00:19:13.260 --> 00:19:18.130
fully open source toolchain, thanks to
Clifford Wolf and so. And this allows us
00:19:18.130 --> 00:19:23.230
to very, very quickly develop new
triggers, develop new glitched code and so
00:19:23.230 --> 00:19:27.450
on. And it makes compilation and
everything really really fast. It also
00:19:27.450 --> 00:19:31.741
comes with three integrated power
supplies. So we have a 1.2 watt power
00:19:31.741 --> 00:19:38.250
supply, 3.3, 5 volts and so on, and you
can use it for DPA. And this is based
00:19:38.250 --> 00:19:42.880
around some existing devices. So, for
example, the FPGA part is based on the
00:19:42.880 --> 00:19:48.820
1BitSquared iCEBreaker. The analog front
end, thanks to Colin O'Flynn, is based on
00:19:48.820 --> 00:19:53.570
the ChipWhisperer Nano. And then the
glitch circuit is basically what we've
00:19:53.570 --> 00:19:58.520
been using on bread boards for quite a
while. Just combined on a single device.
00:19:58.520 --> 00:20:02.549
And so unfortunately, as always with
hardware production takes longer than you
00:20:02.549 --> 00:20:07.440
might assume. But if you drop me a message
on Twitter, I'm happy to send you a PCB as
00:20:07.440 --> 00:20:13.440
soon as they work well. And the BOM is
around 50 bucks. Cool. So now that we are
00:20:13.440 --> 00:20:19.580
ready to have to actually attack chips,
let's look at an example. So the very
00:20:19.580 --> 00:20:25.390
first chip that I encountered that used
TrustZone-M was the Microchip SAM 11. And
00:20:25.390 --> 00:20:32.010
so this chip was released in June 2018.
And it's kind of it's a small, slow chip.
00:20:32.010 --> 00:20:37.929
It's runs at 32 megahertz. It has up to 64
kilobytes of flash and 16 kilobytes of
00:20:37.929 --> 00:20:44.210
SRAM, but it's super cheap. It's like one
dollar eighty at quantity one. And so it's
00:20:44.210 --> 00:20:50.230
really nice, really affordable. And we had
people come up to us and suggest, hey, I
00:20:50.230 --> 00:20:54.659
want to build a TPM on top of this or I
want to build a hardware wallet on top of
00:20:54.659 --> 00:21:01.120
this. And so on and so forth. And if we
look at the website of this chip. It has a
00:21:01.120 --> 00:21:06.530
lot of security in it, so it's the best
contribution to IOT security winner of
00:21:06.530 --> 00:21:14.899
2018. And if you just type secure into the
word search, you get like 57 hits. So this
00:21:14.899 --> 00:21:23.610
chip is 57 secure. laughter And even on
the website itself, you have like chip
00:21:23.610 --> 00:21:28.700
level security. And then if you look at
the first of the descriptions, you have a
00:21:28.700 --> 00:21:33.950
robust chip level security include chip
level, tamper resistance, active shield
00:21:33.950 --> 00:21:38.301
protects against physical attacks and
resists micro probing attacks. And even in
00:21:38.301 --> 00:21:42.440
the datasheet, where I got really worried
because I said I do a lot with a core
00:21:42.440 --> 00:21:47.649
voltage it has a brown-out detector that
has been calibrated in production and must
00:21:47.649 --> 00:21:53.809
not be changed and so on. Yeah. To be
fair, when I talked to my microchip, they
00:21:53.809 --> 00:21:58.490
mentioned that they absolutely want to
communicate that this chip is not hardened
00:21:58.490 --> 00:22:03.680
against hardware attacks, but I can see
how somebody who looks at this would get
00:22:03.680 --> 00:22:10.550
the wrong impression given all the terms
and so on. Anyway, so let's talk about the
00:22:10.550 --> 00:22:16.669
TrustZone in this chip. So the SAM L11
does not have a security attribution unit.
00:22:16.669 --> 00:22:21.270
Instead, it only has the implementation
defined attribution unit. And the
00:22:21.270 --> 00:22:25.580
configuration for this implementation
defined attribution unit is stored in the
00:22:25.580 --> 00:22:29.789
user row, which is basically the
configuration flash. It's also called
00:22:29.789 --> 00:22:33.610
fuses in the data sheet sometimes, but
it's really I think it's flash based. I
00:22:33.610 --> 00:22:36.750
haven't checked, but I am pretty sure it
is because you can read it, write it,
00:22:36.750 --> 00:22:42.190
change it and so on. And then the IDAU,
once you've configured it, will be
00:22:42.190 --> 00:22:49.370
configured by the boot ROM during the
start of the chip. And the idea behind the
00:22:49.370 --> 00:22:54.100
IDAU is that all your flash is partitioned
into two parts of the bootloader part and
00:22:54.100 --> 00:23:00.289
the application part, and both of these
can be split into secure, non secure
00:23:00.289 --> 00:23:05.100
callable and non secure. So you can have a
bootloader, a secure and a non secure one,
00:23:05.100 --> 00:23:09.510
and you can have an application, a secure
and a non secure one. And the size of
00:23:09.510 --> 00:23:14.040
these regions is controlled by these five
registers. And for example, if we want to
00:23:14.040 --> 00:23:18.740
change our non secure application to be
bigger and make our secure application a
00:23:18.740 --> 00:23:23.649
bit smaller, we just fiddle with these
registers and the sizes will adjust and
00:23:23.649 --> 00:23:31.390
the same with the bootloader. So this is
pretty simple. How do we attack it? My
00:23:31.390 --> 00:23:36.940
goal initially was I want to somehow read
data from the secure world while running
00:23:36.940 --> 00:23:41.559
code in the non secret world. So jump the
security gap. My code in non secure should
00:23:41.559 --> 00:23:47.350
be able to, for example, extract keys from
the secure world and my attack path for
00:23:47.350 --> 00:23:52.790
that was well, I glitched the boot ROM
code that loads the IDAU you
00:23:52.790 --> 00:23:57.140
configuration. But before we can actually
do this, we need to understand, is this
00:23:57.140 --> 00:24:01.549
chip actually glitchable and can we? Is it
susceptible to glitches or do we
00:24:01.549 --> 00:24:07.360
immediately get get thrown out? And so I
used a very simple setup where just had a
00:24:07.360 --> 00:24:13.210
firmware and tried to glitch out of the
loop and enable an LED. And I had success
00:24:13.210 --> 00:24:19.090
in less than five minutes and super stable
glitches almost immediately. Like when I
00:24:19.090 --> 00:24:23.190
saw this, I was 100 percent sure that I
messed up my setup or that the compiler
00:24:23.190 --> 00:24:28.710
optimized out my loop or that I did
something wrong because I never glitch to
00:24:28.710 --> 00:24:33.530
chip in five minutes. And so this was
pretty awesome, but I also spend another
00:24:33.530 --> 00:24:41.549
two hours verifying my setup. So. OK.
Cool, we know that ship is glitchable, so
00:24:41.549 --> 00:24:47.149
let's glitch it. What do we glitch? Well,
if we think about it somewhere during the
00:24:47.149 --> 00:24:53.330
boot ROM, these registers are red from
flash and then some hardware is somehow
00:24:53.330 --> 00:24:57.890
configured. We don't know how because we
can't dump the boot from we don't know
00:24:57.890 --> 00:25:01.539
what's going on in the chip. And the
datasheet has a lot of pages. And I'm a
00:25:01.539 --> 00:25:09.160
millennial. So, yeah, I read what I have
to read and that's it. But my basic idea
00:25:09.160 --> 00:25:14.250
is if we somehow manage to glitch the
point where it tries to read the value of
00:25:14.250 --> 00:25:19.100
the AS Register, we might be able to set
it to zero because most chip peripherals
00:25:19.100 --> 00:25:25.060
will initialize to zero. And if we glitch
with the instruction that reads AS, maybe
00:25:25.060 --> 00:25:30.290
we can make our non secure application
bigger so that we, that actually we can
00:25:30.290 --> 00:25:39.220
read the secure application data because
now it's considered non secure. But.
00:25:39.220 --> 00:25:44.409
Problem 1 The boot ROM is not dumpable. So
we cannot just disassemble it and figure
00:25:44.409 --> 00:25:50.659
out when does it roughly do this. And the
problem 2 is that we don't know when
00:25:50.659 --> 00:25:55.130
exactly this read occures and our glitch
needs to be instruction precise. We need
00:25:55.130 --> 00:26:01.159
to hit just the right instruction to make
this work. And the solution is brute
00:26:01.159 --> 00:26:08.140
force. But I mean like nobody has time for
that. Right? So if the chip boots for 2
00:26:08.140 --> 00:26:12.820
milliseconds. That's a long range we have
to search for glitches. And so very easy
00:26:12.820 --> 00:26:17.160
solution power analysis. And it turns out
that, for example, a riscure has done this
00:26:17.160 --> 00:26:23.029
before where basically they tried to
figure out where in time a JTAG lock is
00:26:23.029 --> 00:26:30.450
set by comparing the power consumption.
And so the idea is, we basically write
00:26:30.450 --> 00:26:35.649
different values to the AS register, then
we collect a lot of power traces and then
00:26:35.649 --> 00:26:41.029
we look for the differences. And this is
relatively simple to do. If you have a
00:26:41.029 --> 00:26:46.429
ChipWhisperer. So. This was my rough
setup. So we just have the ChipWhisperer-
00:26:46.429 --> 00:26:51.740
Lite. We have a breakout with the chip we
want to attack and a programmer. And then
00:26:51.740 --> 00:26:56.710
we basically collect a couple of traces.
And in my case, even just 20 traces are
00:26:56.710 --> 00:27:01.779
enough, which takes, I don't know, like
half a second to run. And if you have 20
00:27:01.779 --> 00:27:07.370
traces in unsecure mode, 20 traces in
secure mode and you compare them, you can
00:27:07.370 --> 00:27:11.230
see that there are clear differences in
the power consumption starting at a
00:27:11.230 --> 00:27:15.470
certain point. And so I wrote a script
that does some more statistics on it and
00:27:15.470 --> 00:27:20.970
so on. And that basically told me the best
glitch candidate starts at 2.18
00:27:20.970 --> 00:27:24.720
milliseconds. And this needs to be so
precise because I said we're in the milli
00:27:24.720 --> 00:27:31.220
and the nano seconds range. And so we want
to make sure that we at the right point in
00:27:31.220 --> 00:27:37.519
time. Now, how do you actually configure?
How do you build the setup where you
00:27:37.519 --> 00:27:44.429
basically you get a success indication
once you broke this? For this, I needed to
00:27:44.429 --> 00:27:50.039
write a firmware that basically attempts
to read secure data. And then if it's
00:27:50.039 --> 00:27:54.139
successful, enabled the GPIO. And if it
fails, it does nothing. And I just reset
00:27:54.139 --> 00:27:59.460
and try again. And so I know I knew my
rough delay and I was triggering of the
00:27:59.460 --> 00:28:04.590
reset of the chip that I just tried. Any
delay after it and tried different glitch
00:28:04.590 --> 00:28:11.169
pulse length and so on. And eventually I
had a success. And these glitches you will
00:28:11.169 --> 00:28:16.029
see with the glitcher which we released a
while back is super easy to write because
00:28:16.029 --> 00:28:21.940
all you have is like 20 lines of Python.
You basically set up a loop delay from
00:28:21.940 --> 00:28:28.320
delay to your setup, the pulse length. You
iterate over a range of pulses. And then
00:28:28.320 --> 00:28:34.250
in this case you just check whether your
GPIO is high or low. That's all it takes.
00:28:34.250 --> 00:28:38.309
And then once you have this running in a
stable fashion, it's amazing how fast it
00:28:38.309 --> 00:28:43.190
works. So this is now a recorded video of
a life glitch, of a real glitch,
00:28:43.190 --> 00:28:49.730
basically. And you can see we have like 20
attempts per second. And after a couple of
00:28:49.730 --> 00:28:57.370
seconds, we actually get a success
indication we just broke a chip. Sweet.
00:28:57.370 --> 00:29:02.049
But one thing I moved to a part of Germany
to the very south is called the
00:29:02.049 --> 00:29:09.590
Schwabenland. And I mean, 60 bucks. We are
known to be very cheap and 60 bucks
00:29:09.590 --> 00:29:15.440
translates to like six beers at
Oktoberfest. Just to convert this to the
00:29:15.440 --> 00:29:24.460
local currency, that's like 60 Club Mate.
Unacceptable. We need to go cheaper, much
00:29:24.460 --> 00:29:33.650
cheaper, and so.
laughter and applause
00:29:33.650 --> 00:29:40.380
What if we take a chip that is 57 secure
and we tried to break it with the smallest
00:29:40.380 --> 00:29:46.730
chip. And so this is an ATTiny which
costs, I don't know, a a euro or two euro.
00:29:46.730 --> 00:29:52.929
We combine it with a MOSFET to keep the
comparison that's roughly 3 Club Mate and
00:29:52.929 --> 00:29:57.820
we hook it all up on a jumper board and
turns out: This works like you can have a
00:29:57.820 --> 00:30:02.649
relatively stable glitch, a glitcher with
like 120 lines of assembly running all the
00:30:02.649 --> 00:30:07.019
ATTiny and this will glitch your chip
successfully and can break TrustZone on
00:30:07.019 --> 00:30:13.590
the SAM L11. The problem is chips are very
complex and it's always very hard to do an
00:30:13.590 --> 00:30:17.830
attack on a chip that you configured
yourself because as you will see, chances
00:30:17.830 --> 00:30:21.380
are very high that you messed up the
configuration and for example, missed a
00:30:21.380 --> 00:30:26.020
security bit, forgot to set something and
so on and so forth. But luckily, in the
00:30:26.020 --> 00:30:32.169
case of the SAM L11, there's a version of
this chip which is already configured and
00:30:32.169 --> 00:30:39.590
only ships in non secure mode. And so this
is called the SAM L11 KPH. And so it comes
00:30:39.590 --> 00:30:43.990
pre provisioned with a key and it comes
pre provisioned with a trusted execution
00:30:43.990 --> 00:30:49.750
environment already loaded into the secure
part of the chips and ships completely
00:30:49.750 --> 00:30:54.700
secured and the customer can write and
debug non secure code only. And also you
00:30:54.700 --> 00:30:59.620
can download the SDK for it and write your
own trustlets and so on. But I couldn't
00:30:59.620 --> 00:31:04.289
because it requires you to agree to their
terms and conditions so which exclude
00:31:04.289 --> 00:31:08.980
reverse engineering. So no chance,
unfortunately. But anyway, this is the
00:31:08.980 --> 00:31:14.601
perfect example to test our attack. You
can buy these chips on DigiKey and then
00:31:14.601 --> 00:31:18.990
try to break into the secure world because
these chips are hopefully decently secured
00:31:18.990 --> 00:31:24.779
and have everything set up and so on. And
yeah. So this was the setup. We designed
00:31:24.779 --> 00:31:29.779
our own breakout port for the SAM L11,
which makes it a bit more accessible, has
00:31:29.779 --> 00:31:35.100
JTAG and has no capacitors in the way. So
you get access to all the core voltages
00:31:35.100 --> 00:31:42.130
and so on and you have the FPGA on the top
left the super cheap 20 bucks power supply
00:31:42.130 --> 00:31:47.220
and the programmer. And then we just
implemented a simple function that uses
00:31:47.220 --> 00:31:53.230
openOCD to try to read an address that we
normally can't read. So we basically we
00:31:53.230 --> 00:31:59.029
glitch. Then we start OpenOCD, which uses
the JTAG adapter to try to read secure
00:31:59.029 --> 00:32:10.320
memory. And so I hooked it all up, wrote a
nice script and let it rip. And so after a
00:32:10.320 --> 00:32:16.980
while or in well, a couple of seconds
immediately again got successful, I got a
00:32:16.980 --> 00:32:20.340
successful attack on the chip and more and
more. And you can see just how stable you
00:32:20.340 --> 00:32:26.610
can get these glitches and how well you
can attack this. Yeah. So sweet hacked. We
00:32:26.610 --> 00:32:31.309
can compromise the root of trust and the
trusted execution environment. And this is
00:32:31.309 --> 00:32:36.080
perfect for supply chain attacks. Right.
Because if you can compromise a part of
00:32:36.080 --> 00:32:42.139
the chip that the customer will not be
able to access, he will never find you.
00:32:42.139 --> 00:32:45.769
But the problem with supply chain attacks
is, they're pretty hard to scale and they
00:32:45.769 --> 00:32:51.140
are only for sophisticated actors normally
and far too expensive is what most people
00:32:51.140 --> 00:32:58.779
will tell you, except if you hack the
distributor. And so as I guess last year
00:32:58.779 --> 00:33:04.341
or this year, I don't know, I actually
found a vulnerability in DigiKey, which
00:33:04.341 --> 00:33:09.179
allowed me to access any invoice on
DigiKey, including the credentials you
00:33:09.179 --> 00:33:16.779
need to actually change the invoice. And
so basically the bug is that they did not
00:33:16.779 --> 00:33:20.770
check when you basically requested an
invoice, they did not check whether you
00:33:20.770 --> 00:33:25.509
actually had permission to access it. And
you have the web access id on top and the
00:33:25.509 --> 00:33:30.370
invoice number. And that's all you need to
call DigiKey and change the delivery,
00:33:30.370 --> 00:33:37.169
basically. And so this also is all data
that you need to reroute the shipment. I
00:33:37.169 --> 00:33:41.490
disclosed this. It's fixed. It's been
fixed again afterwards. And now hopefully
00:33:41.490 --> 00:33:45.990
this should be fine. So I feel good to
talk about it. And so let's walk through
00:33:45.990 --> 00:33:52.050
the scenarios. We have Eve and we have
DigiKey and Eve builds this new super
00:33:52.050 --> 00:33:58.090
sophisticated IOT toilet and she needs a
secure chip. So she goes to DigiKey and
00:33:58.090 --> 00:34:06.610
orders some SAM L11 KPHs and Mallory.
Mallory scans all new invoices on DigiKey.
00:34:06.610 --> 00:34:13.240
And as soon as somebody orders a SAM L11,
they talk to DigiKey with the API or via a
00:34:13.240 --> 00:34:17.840
phone call to change the delivery address.
And because you know who the chips are
00:34:17.840 --> 00:34:23.409
going to, you can actually target this
very, very well. So now the chips get
00:34:23.409 --> 00:34:30.450
delivered to Mallory Mallory backdoors the
chips. And then sends the backdoored chips
00:34:30.450 --> 00:34:34.419
to Eve who is none the wiser, because it's
the same carrier, it's the same, it looks
00:34:34.419 --> 00:34:38.149
the same. You have to be very, very
mindful of these types of attack to
00:34:38.149 --> 00:34:43.310
actually recognize them. And even if they
open the chips and they say they open the
00:34:43.310 --> 00:34:48.530
package and they try the chip, they scan
everything they can scan the backdoor will
00:34:48.530 --> 00:34:53.580
be in the part of the chip that they
cannot access. And so we just supply chain
00:34:53.580 --> 00:35:02.329
attacked whoever using an UPS envelope,
basically. So, yeah. Interesting attack
00:35:02.329 --> 00:35:07.119
vector. So I talked to microchip and it's
been great. They've been super nice. It
00:35:07.119 --> 00:35:13.460
was really a pleasure. I also talked to
Trustonic, who were very open to this and
00:35:13.460 --> 00:35:19.890
wanted to understand it. And so it was
great. And they explicitly state that this
00:35:19.890 --> 00:35:23.760
chip only protects against software
attacks while it has some hardware
00:35:23.760 --> 00:35:29.530
features like tamper ressistant RAM. It is
not built to withstand fault injection
00:35:29.530 --> 00:35:34.130
attacks. And even if you compare it now,
different revisions of the data sheet, you
00:35:34.130 --> 00:35:38.760
can see that some data sheets, the older
ones they mention some fault injection
00:35:38.760 --> 00:35:42.550
resistance and it's now gone from the data
sheet. And they are also asking for
00:35:42.550 --> 00:35:46.980
feedback on making it more clear what this
chip protects against, which I think is a
00:35:46.980 --> 00:35:52.620
noble goal because we all know marketing
versus technicians is always an
00:35:52.620 --> 00:36:00.580
interesting fight. Let's say, cool first
chip broken time for the next one, right?
00:36:00.580 --> 00:36:07.270
So the next chip I looked at was the
Nuvoton NuMicro M2351 rolls off the
00:36:07.270 --> 00:36:14.150
tongue. It's a Cortex-M23 processor. It
has TrustZone-M. And I was super excited
00:36:14.150 --> 00:36:19.690
because this finally has an SAU, a
security attribution unit and an IDAU and
00:36:19.690 --> 00:36:23.490
also I talked to the marketing. It
explicitly protects against fault
00:36:23.490 --> 00:36:31.790
injection. So that's awesome. I was
excited. Let's see how that turns out.
00:36:31.790 --> 00:36:37.010
Let's briefly talk about the TrustZone in
the Nuvoton chip. So as I've mentioned
00:36:37.010 --> 00:36:45.329
before, the SAU if it's turned off or
turned on without regions will be to fully
00:36:45.329 --> 00:36:49.630
secure. And no matter what the IDAU is,
the most privileged level always wins. And
00:36:49.630 --> 00:36:55.150
so if our entire security attribution unit
is secure, our final security state will
00:36:55.150 --> 00:37:00.880
also be secure. And so if we now add some
small regions, the final state will also
00:37:00.880 --> 00:37:08.240
have the small, non secure regions. I
mean, I saw this looked at how this this
00:37:08.240 --> 00:37:14.980
code works. And you can see that at the
very bottom SAU control is set to 1 simple
00:37:14.980 --> 00:37:19.340
right. We glitch over the SAU enabling and
all our code will be secure and we'll just
00:37:19.340 --> 00:37:26.480
run our code in secret mode, no problem -
is what I fought. And so basically the
00:37:26.480 --> 00:37:31.201
secure bootloader starts execution of non
secure code. We disable the SAU by
00:37:31.201 --> 00:37:35.859
glitching over the instruction and now
everything is secure. So our code runs in
00:37:35.859 --> 00:37:43.700
a secure world. It's easy except read the
fucking manual. So turns out these
00:37:43.700 --> 00:37:49.760
thousands of pages of documentation
actually contain useful information and
00:37:49.760 --> 00:37:55.060
you need a special instruction to
transition from secure to non secure state
00:37:55.060 --> 00:38:02.230
which is called BLXNS, which stands for
branch optionally linked and exchange to
00:38:02.230 --> 00:38:08.300
non secure. This is exactly made to
prevent this. It prevents accidentally
00:38:08.300 --> 00:38:13.290
jumping into non secure code. It will
cause a secure fault if you try to do it.
00:38:13.290 --> 00:38:19.390
And what's interesting is that even if you
use this instruction, it will not always
00:38:19.390 --> 00:38:24.530
transition. The state depends on the last
bit in the destination address, whether
00:38:24.530 --> 00:38:30.060
the status transition and the way the
bootloader will actually get these
00:38:30.060 --> 00:38:34.410
addresses it jumps to is from what's
called the reset table, which is basically
00:38:34.410 --> 00:38:38.610
where your reset handlers are, where your
stack pointer, your initial stack pointer
00:38:38.610 --> 00:38:43.710
is and so on. And you will notice that the
last bit is always set. And if the last
00:38:43.710 --> 00:38:49.600
bit is set, it will jump to secure code.
So somehow they managed to branch to this
00:38:49.600 --> 00:38:56.790
address and run it into non secure. So how
do they do this? They use an explicit bit
00:38:56.790 --> 00:39:02.700
clear instruction. What do we know about
instructions? We can glitch over them. And
00:39:02.700 --> 00:39:09.109
so basically we can with two glitches, we
can glitch over the SAU control enable now
00:39:09.109 --> 00:39:16.369
our entire memory is secure and then we
glitch over the bitclear instruction and
00:39:16.369 --> 00:39:23.609
then branch linked ex non secure again
rolls off the tongue will run secure code.
00:39:23.609 --> 00:39:29.260
And now our normal world code is running
in secure mode. The problem is it works,
00:39:29.260 --> 00:39:33.780
but it's very hard to get stable. So, I
mean, this was I somehow got it working,
00:39:33.780 --> 00:39:40.840
but it was not very stable and it was a
big pain to to actually make use of. So I
00:39:40.840 --> 00:39:45.010
wanted a different vulnerability. And I
read up on the implementation defined
00:39:45.010 --> 00:39:52.190
attribution unit of the M2351. And it
turns out that each flash RAM peripheral
00:39:52.190 --> 00:39:59.780
and so on is mapped twice into memory. And
so basically once as secure as the address
00:39:59.780 --> 00:40:08.710
0x2000 and once as non secure at the
address 0x3000. And so you have the flash
00:40:08.710 --> 00:40:15.410
twice and you have the the RAM twice. This
is super important. This is the same
00:40:15.410 --> 00:40:22.220
memory. And so I came up with an attack
that I called CroeRBAR because a
00:40:22.220 --> 00:40:27.820
vulnerability basically doesn't exist if
it doesn't have a fancy name. And the
00:40:27.820 --> 00:40:32.079
basic point of this is that the security
of the system relies on the region
00:40:32.079 --> 00:40:36.569
configuration of the SAU. What if we
glitch this initialization combined with
00:40:36.569 --> 00:40:43.170
this IDAU layout again with the IDAU
mirrors the memory. Has it once a secure
00:40:43.170 --> 00:40:48.500
and once it's not secure. Now let's say we
have at the very bottom of our flash. We
00:40:48.500 --> 00:40:54.520
have a secret which is in the secure area.
It will also be in the mirror of this
00:40:54.520 --> 00:41:00.550
memory. But again, because our SAU
configuration is fine, it will not be
00:41:00.550 --> 00:41:06.309
accessible by the non secure region.
However, the start of this non secret area
00:41:06.309 --> 00:41:14.339
is configured by the RBAR register. And so
maybe if we glitch this RBAR being set, we
00:41:14.339 --> 00:41:18.210
can increase the size of the non secure
area. And if you check the ARM
00:41:18.210 --> 00:41:22.950
documentation on the RBAR register, the
reset values state of this register is
00:41:22.950 --> 00:41:28.079
unknown. So unfortunately it doesn't just
say zero, but I tried this on all chips I
00:41:28.079 --> 00:41:33.839
had access to and it is zero on all chips
I tested. And so now what we can do is we
00:41:33.839 --> 00:41:38.800
glitch over this RBAR and now our final
security state will be bigger and our
00:41:38.800 --> 00:41:43.390
secure code is still running in the bottom
half. But then the jump into non secure
00:41:43.390 --> 00:41:50.750
will also give us access to the secret and
it works. We get a fully stable glitch,
00:41:50.750 --> 00:41:56.650
takes roughly 30 seconds to bypass it. I
should mention that this is what I think
00:41:56.650 --> 00:42:00.440
happens. All I know is that I inject a
glitch and I can read the secret. I cannot
00:42:00.440 --> 00:42:05.180
tell you exactly what happens, but this is
the best interpretation I have so far. So
00:42:05.180 --> 00:42:10.970
wuhu we have an attack with a cool name?
And so I looked at another chip called the
00:42:10.970 --> 00:42:18.930
NXP LPC55S69, and this one has 2
Cortex-M33 cores, one of which has
00:42:18.930 --> 00:42:26.599
TrustZone-M. The IDAU and the overall
TrustZone layout seem to be very similar
00:42:26.599 --> 00:42:31.640
to the NuMicro. And I got the dual glitch
attack working and also the CrowRBAR
00:42:31.640 --> 00:42:38.730
attack working. And the vendor response
was amazing. Like holy crap, they called
00:42:38.730 --> 00:42:42.500
me and wanted to fully understand it. They
reproduced that. They got me on the phone
00:42:42.500 --> 00:42:48.250
with an expert and the expert was super
nice. But what he said came down to was
00:42:48.250 --> 00:42:55.480
RTFM. But again, this is a long document,
but it turns out that the example code did
00:42:55.480 --> 00:43:01.900
not enable a certain security feature. And
this security feature is helpfully named
00:43:01.900 --> 00:43:10.820
Miscellaneous Control Register, basically,
laughter which stands for Secure Control
00:43:10.820 --> 00:43:21.120
Register, laughter obviously. And this
register has a bit. If you set it, it
00:43:21.120 --> 00:43:26.640
enables secure checking. And if I read
just a couple of sentences first further,
00:43:26.640 --> 00:43:31.119
when I read about the TrustZone on the
chip, I would have actually seen this. But
00:43:31.119 --> 00:43:37.630
Millennial sorry. Yeah. And so what this
enables is called the memory protection
00:43:37.630 --> 00:43:41.420
checkers and this is an additional memory
security check that gives you finer
00:43:41.420 --> 00:43:46.481
control over the memory layout. And so it
basically checks if the attribution unit
00:43:46.481 --> 00:43:51.870
security state is identical with the
memory protection checker security state.
00:43:51.870 --> 00:43:57.960
And so, for example, if our attack code
tries to access memory, the MPC will check
00:43:57.960 --> 00:44:04.280
whether this was really a valid request.
So to say and stop you if you are unlucky
00:44:04.280 --> 00:44:10.250
as I was. But turns out it's glitchable,
but it's much, much harder to glitch and
00:44:10.250 --> 00:44:15.550
you need multiple glitches. And the vendor
response was awesome. They also say
00:44:15.550 --> 00:44:22.010
they're working on improving the
documentation for this. So yeah, super
00:44:22.010 --> 00:44:26.770
cool. But still like it's not a full
protection against glitching, but it gives
00:44:26.770 --> 00:44:33.041
you certain security. And I think that's
pretty awesome. Before we finish. Is
00:44:33.041 --> 00:44:38.260
everything broken? No. These chips are not
insecure. They are not protected against a
00:44:38.260 --> 00:44:43.930
very specific attack scenario and align
the chips that you want to use with your
00:44:43.930 --> 00:44:47.510
threat model. If fault injection is part
of your threat models. So, for example,
00:44:47.510 --> 00:44:51.700
you're building a carkey. Maybe you should
protect against glitching. If you're
00:44:51.700 --> 00:44:56.340
building a hardware wallet, definitely you
should protect against glitching. Thank
00:44:56.340 --> 00:45:00.829
you. Also, by the way, if you want to play
with some awesome fault injection
00:45:00.829 --> 00:45:05.579
equipment, I have an EMFI glitcher with me
and so. So just hit me up on Twitter and
00:45:05.579 --> 00:45:09.540
I'm happy to show it to you. So thanks a
lot.
00:45:09.540 --> 00:45:17.700
applause
00:45:17.700 --> 00:45:24.780
Herald: Thank you very much, Thomas. We do
have an awesome 15 minutes for Q and A. So
00:45:24.780 --> 00:45:30.391
if you line up, we have three microphones.
Microphone number 3 actually has an
00:45:30.391 --> 00:45:34.119
induction loop. So if you're hearing
impaired and have a suitable device, you
00:45:34.119 --> 00:45:39.130
can go to microphone 3 and actually hear
the answer. And we're starting off with
00:45:39.130 --> 00:45:41.980
our signal angel with questions from the
Internet.
00:45:41.980 --> 00:45:47.710
Thomas: Hello, Internet.
Signal Angel: Hello. Are you aware of the
00:45:47.710 --> 00:45:53.560
ST Cortex-M4 firewall? And can your
research be somehow related to it? Or
00:45:53.560 --> 00:45:56.880
maybe do you have plans to explore it in
the future?
00:45:56.880 --> 00:46:02.440
Thomas: I. So, yes, I'm very aware of the
ST M3 and M4. If you watch our talk last
00:46:02.440 --> 00:46:06.680
year at CCC called Wallet.fail, we
actually exploited the sister chip, the
00:46:06.680 --> 00:46:12.950
STM32 F2. The F4 has this strange firewall
thing which feels very similar to
00:46:12.950 --> 00:46:18.680
TrustZone-M. However, I cannot yet share
any research related to that chip,
00:46:18.680 --> 00:46:22.090
unfortunately. Sorry.
Signal Angel: Thank you.
00:46:22.090 --> 00:46:28.720
Herald: Microphone number 1, please.
Mic 1: Hello. I'm just wondering, have you
00:46:28.720 --> 00:46:34.280
tried to replicate this attack on
multicore CPUs with higher frequency such
00:46:34.280 --> 00:46:38.859
like 2GHz and others, how would you go
about that?
00:46:38.859 --> 00:46:43.599
Thomas: So I have not because there there
are no TrustZone-M chips with this
00:46:43.599 --> 00:46:48.190
frequency. However, people have done it on
mobile phones and other equipment. So, for
00:46:48.190 --> 00:46:54.960
example, yeah, there's a lot of materials
on glitching higher frequency stuff. But
00:46:54.960 --> 00:46:59.170
yeah, it will get expensive really quickly
because the scope, the way you can even
00:46:59.170 --> 00:47:03.819
see a two gigahertz clock, that's a nice
car oscilloscope.
00:47:03.819 --> 00:47:09.410
Herald: Microphone number 2, please.
Mic 2: Thank you for your talk. Is the
00:47:09.410 --> 00:47:15.750
more functionality to go from non-secure
to secure area? Are there same standard
00:47:15.750 --> 00:47:19.740
defined functionalities or the proprietory
libraries from NXP?
00:47:19.740 --> 00:47:25.130
Thomas: So the the veneer stuff is
standard and you will find ARM documents
00:47:25.130 --> 00:47:29.299
basically recommending you to do this. But
all the tool chains, for example, the one
00:47:29.299 --> 00:47:34.799
for the SAM L11 will generate the veneers
for you. And so I have to be honest, I
00:47:34.799 --> 00:47:37.900
have not looked at how exactly they are
generated.
00:47:37.900 --> 00:47:42.480
However, I did some rust stuff to play
around with it. And yeah, it's relatively
00:47:42.480 --> 00:47:44.751
simple for the tool chain and it's
standard. So
00:47:44.751 --> 00:47:51.720
Herald: the signal angel is signaling.
Signal Angel: Yeah. That's not another
00:47:51.720 --> 00:47:56.180
question from the internet but from me and
I wanted to know how important is the
00:47:56.180 --> 00:48:00.680
hardware security in comparison to the
software security because you cannot hack
00:48:00.680 --> 00:48:06.490
these devices without having physical
access to them except of this supply chain
00:48:06.490 --> 00:48:09.300
attack.
Thomas: Exactly. And that depends on your
00:48:09.300 --> 00:48:14.210
threat model. So that's basically if you
build a door, if you build a hardware
00:48:14.210 --> 00:48:18.280
wallet, you want to have hardware
protection because somebody can steal it
00:48:18.280 --> 00:48:22.200
potentially very easily and then... And if
you, for example, look at your phone, you
00:48:22.200 --> 00:48:27.720
probably maybe don't want to have anyone
at customs be able to immediately break
00:48:27.720 --> 00:48:31.339
into your phone. And that's another point
where hardware security is very important.
00:48:31.339 --> 00:48:36.090
And there with a car key, it's the same.
If you rent a car, you hopefully the car
00:48:36.090 --> 00:48:41.920
rental company doesn't want you to copy
the key. And interestingly, the more
00:48:41.920 --> 00:48:45.559
probably one of the most protected things
in your home is your printer cartridge,
00:48:45.559 --> 00:48:49.700
because I can tell you that the vendor
invests a lot of money into you not being
00:48:49.700 --> 00:48:54.500
able to clone the printer cartridge. And
so there are a lot of cases where it's
00:48:54.500 --> 00:48:58.270
maybe not the user who wants to protect
against hardware attacks, but the vendor
00:48:58.270 --> 00:49:02.200
who wants to protect against it.
Herald: Microphone number 1, please.
00:49:02.200 --> 00:49:04.750
Mic 1: So thank you again for the amazing
Talk.
00:49:04.750 --> 00:49:07.730
Thomas: Thank you.
Mic 1: You mentioned higher order attacks,
00:49:07.730 --> 00:49:12.099
I think twice. And for the second chip,
you actually said you you broke it with
00:49:12.099 --> 00:49:14.750
two glitches, two exploiteable glitches.
Thomas: Yes.
00:49:14.750 --> 00:49:19.370
Mic 1: So what did you do to reduce the
search space or did you just search over
00:49:19.370 --> 00:49:22.190
the entire space?
Thomas: So the nice thing about these
00:49:22.190 --> 00:49:27.900
chips is that you can actually you can if
you have a security attribution unit, you
00:49:27.900 --> 00:49:33.720
can decide when you turn it on, because
you can just, I had the GPIO go up. Then I
00:49:33.720 --> 00:49:39.609
enable the SAU. And then I had my search
space very small because I knew it would
00:49:39.609 --> 00:49:45.150
be just after I pulled up the GPIO. And so
I was able to very precisely time where I
00:49:45.150 --> 00:49:50.280
glitch and I was able because I wrote the
code basically that does it. I could
00:49:50.280 --> 00:49:53.470
almost count on the oscilloscope which
instruction I'm hitting.
00:49:53.470 --> 00:49:56.520
Mic 1: Thank you.
Herald: Next question from microphone
00:49:56.520 --> 00:49:59.839
number 2, please.
Mic 2: Thank you for the talk. I was just
00:49:59.839 --> 00:50:05.170
wondering if the vendor was to include the
capacitor directly on the die, howfixed
00:50:05.170 --> 00:50:10.520
would you consider it to be?
Thomas: So against voltage glitching? It
00:50:10.520 --> 00:50:14.530
might help. It depends. But for example,
on a recent chip, we just used the
00:50:14.530 --> 00:50:19.309
negative voltage to suck out the power
from the capacitor. And also, you will
00:50:19.309 --> 00:50:23.820
have EMFI glitching as a possibility and
EMFI glitching is awesome because you
00:50:23.820 --> 00:50:28.140
don't even have to solder. You just
basically put a small coil on top of your
00:50:28.140 --> 00:50:33.070
chip and inject the voltage directly into
it behind any of the capacitors. And so
00:50:33.070 --> 00:50:39.570
on. So it it helps, but it's not a. Often
it's not done for security reasons. Let's
00:50:39.570 --> 00:50:42.650
see.
Herald: Next question again from our
00:50:42.650 --> 00:50:46.359
Signal Angel.
Signal Angel: Did you get to use your own
00:50:46.359 --> 00:50:55.970
custom hardware to help you?
Thomas: I partially the part that worked
00:50:55.970 --> 00:50:59.310
is the summary.
Herald: Microphone number 1, please.
00:50:59.310 --> 00:51:05.010
Mic 1: Hi. Thanks for the interesting
talk. All these vendors pretty much said
00:51:05.010 --> 00:51:08.420
this sort of attack is sort of not really
in scope for what they're doing.
00:51:08.420 --> 00:51:10.880
Thomas: Yes.
Mic 1: Are you aware of anyone like in
00:51:10.880 --> 00:51:15.490
this sort of category of chip actually
doing anything against glitching attacks?
00:51:15.490 --> 00:51:20.190
Thomas: Not in this category, but there
are secure elements that explicitly
00:51:20.190 --> 00:51:25.891
protect against it. A big problem with
researching those is that it's also to a
00:51:25.891 --> 00:51:30.280
large degree security by NDA, at least for
me, because I have no idea what's going
00:51:30.280 --> 00:51:35.450
on. I can't buy one to play around with
it. And so I can't tell you how good these
00:51:35.450 --> 00:51:39.130
are. But I know from some friends that
there are some chips. Are very good at
00:51:39.130 --> 00:51:42.930
protecting against glitches. And
apparently the term you need to look for
00:51:42.930 --> 00:51:47.420
it is called glitch monitor. And if you
see that in the data sheet, that tells you
00:51:47.420 --> 00:51:52.230
that they at least thought about it
Herald: Microphone number 2, please.
00:51:52.230 --> 00:51:59.950
Mic 2: So what about brown-out or
detection? Did microchip say why it didn't
00:51:59.950 --> 00:52:03.490
catch your glitching attempts?
Thomas: It's not meet to glitch it at two
00:52:03.490 --> 00:52:08.170
to catch glitching attacks. Basically, a
brownout detector is mainly there to keep
00:52:08.170 --> 00:52:13.580
your chip stable. And so, for example, if
you're supply voltage drops, you want to
00:52:13.580 --> 00:52:17.210
make sure that you notice and don't
accidentally glitch yourself. So, for
00:52:17.210 --> 00:52:21.250
example, if it is running on a battery and
your battery goes empty, you want your
00:52:21.250 --> 00:52:25.490
chip to run stable, stable, stable off.
And that's the idea behind a brownout
00:52:25.490 --> 00:52:30.590
detector is my understanding. But yeah,
they are not made to be fast enough to
00:52:30.590 --> 00:52:36.119
catch glitching attacks.
Herald: Do we have any more questions from
00:52:36.119 --> 00:52:39.150
the hall?
Thomas: Yes.
00:52:39.150 --> 00:52:45.359
Herald: Yes? Where?
Mic ?: Thank you for your amazing talk.
00:52:45.359 --> 00:52:49.320
You have shown that it gets very
complicated if you have two consecutive
00:52:49.320 --> 00:52:55.390
glitches. So wouldn't it be an easy
protection to just do the stuff twice or
00:52:55.390 --> 00:53:00.809
three times and maybe randomize it? Would
you consider this then impossible to be
00:53:00.809 --> 00:53:04.160
glitched?
Thomas: So adding randomization to the
00:53:04.160 --> 00:53:08.010
point in time where you enable it helps,
but then you can trigger off the power
00:53:08.010 --> 00:53:12.880
consumption and so on. And I should add, I
only tried to to trigger once and then use
00:53:12.880 --> 00:53:16.880
just a simple delay. But in theory, if you
do it twice, you could also glitch on the
00:53:16.880 --> 00:53:21.830
power consumption signature and so on. So
it might help. But somebody very motivated
00:53:21.830 --> 00:53:27.910
will still be able to do it. Probably.
Herald: OK. We have another question from
00:53:27.910 --> 00:53:31.059
the Internet.
Signal Angel: Is there a mitigation for
00:53:31.059 --> 00:53:36.510
such a attack that I can do on PCB level
or it can be addressed only on chip level?
00:53:36.510 --> 00:53:40.250
Thomas: Only on chip level, because if you
have a heat, can you just pull the chip
00:53:40.250 --> 00:53:45.650
off and do it in a socket or if you do
EMFI glitching, you don't even have to
00:53:45.650 --> 00:53:50.240
touch the chip. You just go over it with
the coil and inject directly into the
00:53:50.240 --> 00:53:54.800
chip. So the chip needs to be secured
against this type of stuff or you can add
00:53:54.800 --> 00:54:00.130
a tamper protection case around your
chips. So, yeah.
00:54:00.130 --> 00:54:02.700
Herald: Another question from microphone
number 1.
00:54:02.700 --> 00:54:08.270
Mic 1: So I was wondering if you've heard
anything or know anything about the STM32
00:54:08.270 --> 00:54:11.260
L5 series?
Thomas: I've heard a lot. I've seen
00:54:11.260 --> 00:54:17.020
nothing. So, yes, I've heard about it. But
it doesn't ship yet as far as I know. We
00:54:17.020 --> 00:54:20.470
are all eagerly awaiting it.
Mic 1: Thank you.
00:54:20.470 --> 00:54:24.440
Herald: Microphone number 2, please
Mic 2: Hey, very good talk. Thank you. Do
00:54:24.440 --> 00:54:29.089
you, Will you release all the hardware
design of the board and those scripts?
00:54:29.089 --> 00:54:30.799
Thomas: Yes.
Mic 2: Is there anything already
00:54:30.799 --> 00:54:33.109
availability even if I understood it's not
all finished?
00:54:33.109 --> 00:54:38.349
Thomas: Oh, yes. So on chip.fail. There
are thoughtful domains. It's awesome.
00:54:38.349 --> 00:54:44.160
Chip.fail has the source code to our
glitcher. I've also ported it to the
00:54:44.160 --> 00:54:48.990
Lattice and I need to push that hopefully
in the next few days. But then all the
00:54:48.990 --> 00:54:53.109
hardware would be open sourced also
because it's based on open source hardware
00:54:53.109 --> 00:54:59.100
and yeah, I'm not planning to make any
money or anything using it. It's just to
00:54:59.100 --> 00:55:02.590
make life easier.
Herald: Microphone number 2, please.
00:55:02.590 --> 00:55:07.340
Mic 2: So you said already you don't
really know what happens at the exact
00:55:07.340 --> 00:55:14.990
moment of the glitch and you were lucky
that you that you skipped an instruction
00:55:14.990 --> 00:55:24.339
maybe. Do you have. Yes. A feeling what is
happening inside the chip at the moment of
00:55:24.339 --> 00:55:28.730
the glitch?
Thomas: So I asked this precise question,
00:55:28.730 --> 00:55:36.579
what exactly happens to multiple people? I
got multiple answers. But basically my my
00:55:36.579 --> 00:55:41.280
understanding is that you basically pull
the voltage that it needs to set, for
00:55:41.280 --> 00:55:45.770
example, the register. But I'm it's
absolutely out of my domain to give an
00:55:45.770 --> 00:55:50.710
educated comment on this. I'm a breaker,
unfortunately, not a maker when it comes
00:55:50.710 --> 00:55:54.030
to chips.
Herald: Microphone number 2, please.
00:55:54.030 --> 00:56:01.750
Mic 2: OK. Thank you. You said a lot of
the chip attack. Can you tell us something
00:56:01.750 --> 00:56:07.510
about JTAG attacks? So I just have a
connection to JTAG?
00:56:07.510 --> 00:56:12.280
Thomas: Yeah. So, for example, the attack
on the KPH version of the chip was
00:56:12.280 --> 00:56:17.290
basically a JTAG attack. I used JTAG to
read out the chip, but I did have JTAG in
00:56:17.290 --> 00:56:23.630
normal world. However, it's possible on
most - on a lot of chips to reenable JTAG
00:56:23.630 --> 00:56:28.690
even if it's locked. And for example,
again, referencing last year's talk, we
00:56:28.690 --> 00:56:34.330
were able to re enable JTAG on the STM32F2
and I would assume was something similar
00:56:34.330 --> 00:56:39.440
as possible on this chip as well. But I
haven't tried.
00:56:39.440 --> 00:56:47.260
Herald: Are there any more questions we
still have a few minutes. I guess not.
00:56:47.260 --> 00:56:51.600
Well, a big, warm round of applause for
Thomas Roth.
00:56:51.600 --> 00:56:55.110
applause
00:56:55.110 --> 00:56:59.210
postroll music
00:56:59.210 --> 00:57:06.250
Subtitles created by c3subtitles.de
in the year 2021. Join, and help us!